asp.net-mvc – 具有服务层和存储库层的ASP.NET MVC,应该在哪里

这是我自己也问过的事情。我一直有一个愚蠢的问题与你的相似;

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层)中。没关系，只要它适合你。

记住把我的解决方案作为一个想法 – 要考虑的事情;我的做法是试图从最好的方面追踪圣人的建议，但我相信我只是成功了很多;我可以(而且必须)仍然改善。