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

Question

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

我有一个用于实现接口IRepository的存储库的单独项目。 Service有一个单独的项目，它实现了IService并获取了一个IRepository（构造函数注入）。该服务实现了IService。这个例子就足以让控制器实例化服务，而不需要IoC容器。将其视为理解最佳架构实践的中间步骤，这是逐步构建包含依赖注入和可能更多层的序列的一部分。

问题是，我应该在哪里定义IRepository和IService？当然，服务和存储库项目都需要引用它们。很明显，它们应该在服务和存储库项目引用的另一个项目中定义。如果是这样，那么一个好的命名约定是什么？ XXXXContracts之类的东西？

同样，对于在表示层，服务层和存储库层之间传递的数据模型，是否可以使用所有层引用的名为XXXXModels的单独项目？据我所知，在某些情况下，服务层和存储库层之间传递的模型可能与服务层和表示层之间传递的模型不同，但原理是相同的。

我在这里找到了类似问题的答案，但它们往往涉及比我在此概述的更复杂的架构。我希望实现一个非常简单和干净的两层图解，可以看作是参考数据层并在控制器中具有业务逻辑的一两步，这就是全部。我知道有一个强有力的论据可以直接进入全面的最佳实践，但不是每个人都适合一次性完成跳跃。

Answer 1

简介

这也是我自己也问过的。我经常遇到的一个问题与你的问题类似;

  

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

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

搜索后我怀疑答案是它并不重要。重要的是，您的解决方案具有一些合理的架构，并且您尝试遵循SOLID等良好实践。

关于此主题的我的ASP.NET MVC英雄是Jeffrey Palermo，Steve Smith和Jimmy Bogard。

洋葱架构

杰弗里·巴勒莫（Jeffrey Palermo）讨论了旧观念的组合，但将它们结合在一起，并赋予它Onion Architecture的视觉刺激性名称（推荐阅读）。杰弗里展示了一个解决问题的好方法。他解释说，在您的应用程序的中心（或顶部），您拥有核心。您可以在此层放置IRepository和IService等接口。

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

尝试尽可能少地（在合理范围内）引用您的UI图层。在我的一个应用程序中，我的UI（MVC）层仅引用Core。所需的一切都用Dependency Injection注入其中。

史蒂夫史密斯在MVC Solution Best Practices: A solution to the solution problem

中通过演示讨论了洋葱建筑和类似的想法

我的解决方案

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

• MyProject.Core
• MyProject.Domain
• MyProject.DependencyInjection
• MyProject.Infrastructure
• MyProject.Web
• MyProject.Tests

Core 包含我的界面。它通常分为服务，模型，域，存储库等文件夹。

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

DependencyInjection 层包含我选择的DI包/框架和实现细节。我认为它是一个外层;类似于UI或基础设施，所以如果它引用很多就没关系。这个图层不一定是一个单独的项目，许多人会告诉你不要这样做。没关系;做什么适用于您的项目的复杂性。我喜欢我的DI是自己的东西。关于它如此独立的好处是我可以用不同的方式替换DI框架，事情就好了。没有图层参考DI项目。

基础设施层包含有关日志记录，电子邮件和数据访问的信息。它将包含我的ORM选项。这不是商业逻辑的东西，也不是UI的东西。这是我完成任务的解决方案的铁路。它在外层，但它只引用Core。

Web 图层是我的MVC项目，仅引用Core。

复杂性和最终想法

  

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

这是一个好点。记住问题的复杂性非常重要。但不要被良好的解决方案做法所吓倒。我的解决方案和洋葱架构不一定非常复杂，并没有真正膨胀你的解决方案。他们只是将事情分开。

在Evolutionary Project Structure中，吉米·博加德谈到过于复杂的事情。如果我所说的看起来太复杂，请按照Jimmy的建议将其全部放在一个项目（您的UI层）中。没关系 - 只要它适合你。

请记住仅将我的解决方案作为一个想法 - 需要考虑的事情;我的方法是尝试从最好的方面遵循圣人的建议，但我确信我只是取得了如此多的成功;我可以（并且必须）仍在改进。