带有服务层和存储库层的ASP.NET MVC，应该在哪里定义接口？

Question

我正在确定具有存储库层和服务层的.NET MVC应用程序的相当简单的分层体系结构。我发现了一些相当清晰和简单的例子，特别是 www.asp.net, ，以及这里的一些问题和答案，但是我正在寻找更简单的东西，适合小型应用程序，但是使用不同的项目来实现这个想法。我链接到上面的示例将存储库和服务作为模型名称空间中的类。这还不足以使我能够正确说明它。

我有一个单独的项目，用于实现接口Irepository的存储库。该服务有一个分离的项目，可以实施静脉内并采用iRepository（构造函数注入）。该服务实施等级。对于此示例，控制器实例化服务是足够的，目前尚不需要IOC容器。将其视为理解最佳体系结构实践的中间步骤，这是一个逐步构建以包括依赖注入和更多层的序列的一部分。

问题是，我应该在哪里定义iRepository和Iservice？当然，服务和存储库项目都需要参考它们。那时似乎应该在服务和存储库项目引用的另一个项目中定义它们。如果是这样，命名惯例将是什么？像XXXXContracts一样？

同样，对于在演示文稿，服务和存储库层之间传递的数据模型，是否可以接受一个称为XXXXMODELS的单独项目？我知道在某些情况下，在服务和存储库层之间传递的模型可能与服务层和演示层之间传递的模型不同，但是原理是相同的。

我在这里找到了类似问题的答案，但是它们往往涉及比我在这里概述的更复杂的架构。我希望获得两层非常简单明了的说明，可以将其视为上面的一两个步骤，引用数据层并在控制器中具有业务逻辑，仅此而已。我知道直接进行全面的最佳实践有一个强烈而有效的论点，但并不是每个人都适合一口气。

Answer 1

介绍

这也是我也问自己的事情。我总是有一个燃烧的问题与你的相似。

一个好的命名惯例是什么？

我应该如何命名？他们应该进入文件夹或项目吗？

搜索后，我怀疑答案是 真的没关系. 。重要的是，您的解决方案具有一些明智的建筑，并且您尝试遵循良好的做法，例如 坚硬的.

我的ASP.NET MVC英雄是 杰弗里·巴勒莫（Jeffrey Palermo）, 史蒂夫·史密斯 和 吉米·博加德（Jimmy Bogard）.

洋葱架构

杰弗里·巴勒莫（Jeffrey Palermo 洋葱架构 （推荐阅读）。杰弗里（Jeffrey）在何处放置东西的问题表现出了很好的方法。他解释说，在您的应用程序的中心（或顶部） 核. 。这层是您应该放置界面的地方 IRepository 和 IService.

几乎所有的接口都应该进入核心，其他所有（其他项目）都可以参考核心。这样，一切都知道应用程序的骨骼结构而不知道实现细节。

尝试尽可能少地参考UI层参考。在我的一个应用程序中，我的UI（MVC）层仅引用核心。它需要的一切都注入 依赖注射.

史蒂夫·史密斯（Steve Smith）讨论了洋葱建筑和类似的想法 MVC解决方案最佳实践：解决方案问题的解决方案

我的解决方案

在我的MVC解决方案中，我有这样的典型结构：

• myproject.cor
• myproject.domain
• myproject.ipententimentive
• myproject.infrastructure
• myproject.web
• myproject.tests

这 核 包含我的界面。通常将其分为服务，型号，域，存储库等文件夹。

这 领域 图层引用仅核心并包含我的实现。它为核心中的域抽象提供了许多混凝土类。它涉及许多业务逻辑，处理，命令处理，经理课程，具体服务实施等。我认为这是一个相当内在的层，因此它尽可能少。

这 依赖性 图层包含我选择的DI软件包/框架和实现详细信息。我认为这是外层；类似于UI或基础架构，因此，如果它经常引用，则可以。这层没有必要成为一个单独的项目，许多人会告诉您不要这样做。没关系;做的事情适合您项目的复杂性。我喜欢我的di是它自己的事。它是如此分开的好处是，我可以用另一个框架替换DI框架，事情会很好。没有层参考DI项目。

这 基础设施 图层包含有关记录，电子邮件和数据访问的信息。它将包含我的 ORM 选择。这不是商业逻辑的东西，也不是UI的东西。完成工作是我解决方案的铁路。它在外层，但仅引用核心。

这 网络 图层是我的MVC项目，仅引用核心。

复杂性和最终想法

我在这里找到了类似问题的答案，但是它们往往涉及比我在这里概述的更复杂的架构

这是一个好点。重要的是要牢记问题的复杂性。但是不要被良好的解决方案做法所阻止。我的解决方案和洋葱架构不一定非常复杂，也不会真正膨胀您的解决方案。他们只是将事情分开。

在 进化项目结构, ，吉米·博加德（Jimmy Bogard）谈论事情过度复杂。如果我说的话看起来太复杂了，请遵循吉米的建议，并将其全部放在一个项目（您的UI层）中。没关系 - 只要适合您。

记住只将我的解决方案作为一个想法 - 要考虑的事情；我的方法是试图遵循最好的建议，但我敢肯定我只成功了。我仍然可以（而且必须）进步。