我有一个用于实现接口IRepository的存储库的单独项目。服务中有一个分离的项目来实现IService并且需要一个IRepository(构造函数注入)。该服务实现IService。这个例子足以让控制器实例化服务，而不需要IoC容器。认为它是理解最佳架构实践的中间步骤，它是逐渐构建以包括依赖注入和可能更多层的序列的一部分。
问题是我应该在哪里定义IRepository和IService？当然，服务和资源库项目都需要引用它们。看来，应该在服务和资源库项目引用的另一个项目中定义它们。如果是这样，一个好的命名约定是什么？像XXXXContracts这样的东西？
同样，对于在演示，服务和存储库层之间传递的数据模型，是否可以接受所有图层引用的名为XXXXModels的单独项目？据了解，在某些情况下，在服务层和存储库层之间传递的模型可能与服务层和表示层之间传递的模型不同，但原则是相同的。
我在这里找到了类似的问题的答案，但是它们往往涉及比这里概述的更复杂的架构。我正在寻找一个非常简单和干净的两个图层，可以看作是上面一步或两步，引用数据层，并在控制器中拥有业务逻辑，就是这样。我知道有一个坚强有力的论据，直接参加全面的最佳实践，但并不是每个人都适合一次跳跃。
@H_301_10@解决方法
这是我自己也问过的事情。我一直有一个愚蠢的问题与你的相似;
what would a good naming convention be?
我应该怎么命名？他们应该去文件夹还是项目？
搜索后我怀疑答案是没有关系。重要的是，您的解决方案有一些明智的架构，并且您尝试遵循诸如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.Web
> MyProject.Tests
核心包含我的界面。它通常分为文件夹，如服务，模型，域，存储库等。
域层仅引用核心并包含我的实现。它为核心中的域抽象提供了很多具体的类。它处理了很多业务逻辑，处理，命令处理，管理器类，具体的服务实现等。我认为它是一个相当内层，所以它尽可能的参考。
DependencyInjection层包含我选择的DI包/框架和实现细节。我认为它是外层;类似于UI或基础设施，所以没关系，如果它引用很多。这个层不是一个单独的项目，很多人会告诉你不要这样做。没关系;做一些有用的项目的复杂性。我喜欢我的DI成为自己的事情。关于它是如此分开的好处是我可以用不同的替代DI框架，事情会很好。没有图层参考DI项目。
基础设施层包含有关日志记录，电子邮件和数据访问的信息。它将包含我的ORM选择。这不是商业逻辑的东西，它不是UI的东西。我的解决方案的铁路是完成工作。它在外层，但它只引用核心。
Web层是我的MVC项目，仅引用了Core。
复杂性和最终想法
I have found answers to similar questions here,but they tend to involve a more complicated architecture than what I have outlined here
这是一个好点。重要的是要牢记你的问题的复杂性。但不要因为良好的解决方案而被阻止。我的解决方案和洋葱建筑并不一定非常复杂，并不会让您的解决方案变得更糟。他们只是把事情分开。
在Evolutionary Project Structure年，吉米·博加德谈论过于复杂的事情。如果我所说的话似乎太复杂，请按照Jimmy的建议，将其全部放在一个项目(您的UI层)中。没关系，只要它适合你。
记住把我的解决方案作为一个想法 – 要考虑的事情;我的做法是试图从最好的方面追踪圣人的建议，但我相信我只是成功了很多;我可以(而且必须)仍然改善。
@H_301_10@ @H_301_10@