asp.net-mvc - 具有服务层和存储库层的ASP.NET MVC，应在哪里定义接口(interface)？

Question

我正在为具有存储库层和服务层的.NET MVC应用程序确定相当简单的分层体系结构。我找到了一些相当清晰和简单的示例，尤其是www.asp.net，以及此处的一些问题和答案，但我正在寻找更简单，更适合于小型应用程序但使用不同项目的东西，以使您的想法得到传播。 。我上面链接的示例将存储库和服务作为Models名称空间中的类。对于我来说，仅凭清楚的区分就足够了。

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

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

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

我在这里找到了类似问题的答案，但是它们往往涉及比我在此概述的架构更复杂的体系结构。我希望对这两个层实现一个非常简单和干净的说明，这可以看作是引用数据层并在控制器中包含业务逻辑的上面的一个或两个步骤。我知道有一个强有力而有效的论据可以直接寻求成熟的最佳实践，但是并不是每个人都适合一口气。

Answer 1

介绍
这也是我问自己的事情。我经常遇到的一个棘手问题与您的相似。

好的命名约定是什么？

我该如何命名？他们应该放在文件夹或项目中吗？
在四处搜寻之后，我怀疑答案是否真的没有关系。重要的是您的解决方案具有合理的体系结构，并且您尝试遵循良好的实践，例如SOLID。
我在这个主题上的ASP.NET MVC英雄是Jeffrey Palermo，Steve Smith和Jimmy Bogard。
洋葱架构
杰弗里·帕勒莫（Jeffrey Palermo）讨论了旧观念的组合，但将它们组合在一起，并赋予了视觉上令人振奋的Onion Architecture名称（建议阅读）。杰弗里（Jeffrey）展示了一种很好的方法来放置东西。他解释说，在应用程序的中心（或顶部），您拥有核心。在此层中，应放置诸如IRepository和IService之类的接口。
几乎所有接口都应该进入核心，而其他所有项目（其他项目）都可以引用核心。这样，所有人都知道应用程序的骨架结构，而无需了解实现细节。

尽量减少UI层引用（在合理范围内）。在我的一个应用程序中，我的UI（MVC）层仅引用Core。它需要的所有内容都通过Dependency Injection注入其中。
史蒂夫·史密斯（Steve Smith）通过MVC Solution Best Practices: A solution to the solution problem中的演示讨论了洋葱架构和类似的想法
我的解决方案
在我的MVC解决方案中，我具有这样的典型结构：

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

核心包含我的界面。它通常分为服务，模型，域，存储库等文件夹。
域层仅引用核心，并包含我的实现。它为核心中的域抽象提供了许多具体的类。它处理许多业务逻辑，处理，命令处理，管理器类，具体服务实现等。我认为它是相当内层的，因此它引用的内容越少越好。
DependencyInjection层包含我选择的DI包/框架和实现细节。我认为它是一个外层。与UI或基础架构类似，因此可以引用很多。该层不必是一个单独的项目，许多人会告诉您不要这样做。没关系;做适合您项目复杂性的事情。我喜欢自己的DI。如此分离的好处是，我可以用另一个框架替换DI框架，一切都会好起来的。没有图层引用DI项目。
基础结构层包含有关日志记录，电子邮件和数据访问的信息。它将包含我选择的ORM。这不是业务逻辑的东西，也不是UI的东西。这是我完成工作的解决方案。它在外层，但仅引用核心。
Web层是我的MVC项目，并且仅引用Core。
复杂性和最后的想法

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

这是一个好点。重要的是要牢记问题的复杂性。但是，不要被良好的解决方案惯例吓倒。我的解决方案和Onion Architecture不一定很复杂，也不会使您的解决方案肿。他们只是把事情分开。
在Evolutionary Project Structure中，吉米·鲍嘉（Jimmy Bogard）谈到事情过于复杂。如果我说的话似乎过于复杂，请按照吉米的建议，将其全部放在一个项目（您的UI层）中。没关系-只要适合您。
请记住，将我的解决方案仅当作一个想法-需要考虑的事情；我的方法是尝试遵循最好的明智建议，但我确信我仅取得了很大的成功。我可以（而且必须）仍然可以改善。