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

EN

引言

这也是我问过自己的问题。我总是有一个迫切的问题和你的类似；

一个好的命名约定是什么？

我该如何命名呢？它们应该放在文件夹还是项目中？

在四处搜索之后，我怀疑答案是这真的无关紧要。重要的是，您的解决方案具有一些合理的体系结构，并且您尝试遵循良好的实践，如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或Infrastructure，所以如果它引用了很多东西也没问题。这一层没有必要是一个单独的项目，很多人会告诉你不要这样做。这没问题；做适合你项目复杂性的事情吧。我喜欢我的DI是它自己的东西。它如此独立的好处是，我可以用一个不同的DI框架替换它，一切都会好起来的。没有层引用DI项目。

Infrastructure层包含有关日志记录、电子邮件和数据访问的信息。它将包含我选择的ORM。它不是业务逻辑的东西，也不是UI的东西。把事情做好是我解决方案的关键。它位于外层，但它只引用了Core。

MVCWebMVC层是我的项目，它只引用。

复杂性和最终想法

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

这是一个很好的观点。记住问题的复杂性是很重要的。但不要被好的解决方案实践吓倒。我的解决方案和洋葱架构不一定非常复杂，也不会让你的解决方案膨胀。他们只是把事情分开。

在Evolutionary Project Structure中，Jimmy Bogard谈到了事情过于复杂。如果我所说的内容看起来太复杂，请听从Jimmy的建议，并将其全部放入一个项目(您的UI层)中。那没问题--只要它适合你。

记住，我的解决方案只是一个想法--需要考虑的东西；我的方法是试图遵循最好的智者的建议，但我相信我只成功了这么多；我仍然可以(也必须)改进。