如何使用存储库模式、服务模式、UnitOfWork、ORM（EF、NHibernate 等）使用 ASP MVC 构建项目？答案

【问题标题】：How to structure projects with ASP MVC using Repository Pattern, Service Pattern, UnitOfWork, ORM (EF, NHibernate etc..)?如何使用存储库模式、服务模式、UnitOfWork、ORM（EF、NHibernate 等）使用 ASP MVC 构建项目？
【发布时间】：2021-02-11 19:25:18
【问题描述】：

虽然我看到很多关于这个话题的讨论，但我找不到关于这个的非常详细的答案。我想知道我应该在这里和那里放哪个。

我应该把IRepository 接口放在哪里。在 DataAccess 或单独的项目中说“存储库”？其他将扩展 IRepository 的抽象存储库（如 ICustomerRepository : IRepository ）怎么样？他们会驻留在同一个项目上吗？ CustomerRepository : BaseRepository, ICustomerRepository的具体实现如何？

还有我的 POCO，我应该把它们放在哪里？？

UnitOfWork 和服务层？

PS：我的所有服务都可以只包含 UnitOfWork 以便我可以调用任何存储库吗？那里有缺点吗？或者我为什么要在服务上使用存储库而不是 UnitOfWork？

【问题讨论】：

标签： c# asp.net-mvc entity-framework repository-pattern unit-of-work

【解决方案1】：

不是一个明确的答案，希望能给你指明正确的方向

如果您打算使用 ORM，框架会处理 Repository 和 UOW。

这是您可以开始的层 1）UI - 2）服务代理 - 3）服务层 - 4）域层 - 5）存储库

客户到服务如果只有一个客户端要使用服务，则不需要服务层。可能是 Facade 层就足够了，它将与 UI 在同一进程中运行，如果需要支持多个客户端应用程序，可以将其重构为以相对较少的工作量分离服务。抽象所有对服务代理（代理）的服务调用。从 UI 到服务的所有通信都是通过代理进行的。

如果您使用的是服务器端 mvc 框架（例如：asp.net mvc），您可能需要考虑每个屏幕的视图模型。由于大多数屏幕包含来自不同领域模型的数据（订单详细信息 + 运输信息 + 客户详细信息在一个屏幕中），视图模型将整合所有数据以特定于屏幕。在这种情况下，请查看（.net）自动映射器以在 DTO（来自服务的数据）和视图模型之间进行映射，或者构建您自己的轻量级映射器。如果您打算将客户端 MVC 用于 UI（例如：Angular），那么您不需要明确设计视图模型。来自服务的任何东西都将成为您 UI 的模型。

服务到后端服务/外观层 - 这将在域模型上调用适当的方法。从所有 CRUD 的域模型调用存储库中设计 POCO（他们对域进行建模）。内部存储库可以使用 ORM。如果您出于某种原因不使用 ORM，则可能必须构建一些通用代码来将数据从数据库/任何其他数据存储映射到域模型。

为领域层、存储库和服务层中的所有类定义类接口（无论如何框架都会强制你使用服务接口）。请记住在服务/外观上设计粗粒度接口，否则您最终会在 UI 和服务之间调用太多

为每一层创建一个单独的项目，采用一个平均复杂度用例，开始使用所有层、实体类型（视图模型、dto、域模型）、映射器（Viewmodel-dto、dto-领域模型）。我会说将所有接口与具体类项目放在单独的项目中，因为接口属于客户端。这将确保客户不会直接依赖于具体的实施项目。识别 IOC 容器，使用它向其客户端注入依赖项。例如：使用 DI 将域模型注入服务层中的类。配置 DI 以在所有层中注入具体实现（服务将使用 DI 获取域模型，域模型将使用 DI 获取存储库）。如果您使用 DI，它将使您对接口进行编码，这很好。重要的是重构接口、类、方法和结构，直到您觉得整体结构看起来不错，因为您为第一个用例实现的任何高级设计几乎都会成为所有其他用例的模板。

完成一个用例后，您和您的团队将花费更多精力学习/设计/讨论领域模型（阅读 Eric Evans 的领域驱动设计 - 领域驱动设计作者/创建者）。有这么多事情，考虑从哪里开始以及如何开始可能会很混乱。正如我所说，从每一层的项目开始，在重构时添加/删除，并且经常重构。

我认为项目相当复杂。

【讨论】：

如果我有 ICustomerRepo 和 CustomerService ：ICustomerService 是否意味着 CustomerService 应该只包含 ICustomerRepo 而不是其他存储库？存储库应该只包含哪些方法？服务怎么样？

【解决方案2】：

这取决于您的项目的复杂性，但一般的方法是将抽象放在自己的库中，然后从您的 Web 项目中引用它。您可以再次将实现类放在它自己的库中。所以 web 项目不会直接依赖它们

【讨论】：

【解决方案3】：

在“Microsoft Spain - Domain Oriented N-Layered .NET 4.0 Sample App”中，您的所有问题都得到了非常仔细的回答。

http://microsoftnlayerapp.codeplex.com

我建议您先阅读文档，然后再研究示例应用程序。

阅读 Eric Evans 的“领域驱动设计：解决软件核心的复杂性”会很有帮助。这本书就像一本领域驱动设计的圣经。

http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215

【讨论】：

感谢您的链接！我有书。但我让我把所有这些东西都放在我的脑海里:)

【解决方案4】：

几个月前我也有同样的问题。我从来没有真正找到现代 .NET 解决方案架构的权威指南。那时，我的愿望清单包括：

分层架构

依赖注入

通用存储库

模拟单元测试

所以我在网上单独查看每个主题，并从各种博客文章和文章中借用点点滴滴，直到我或多或少得到我想要的东西。

搜索“asp.net repository pattern”和“asp.net mvc solution structure”你会得到很多stackoverflow的命中，只是阅读一些讨论并使用你喜欢的想法。

【讨论】：

是的，我去过那里。但是一些架构示例声称他们不再使用它们并构建了另一种设计，这让我三思而后行以适应这些设计。

【解决方案5】：

见answer on howto create/setup architecture

并不是说它是完美的，但它会给你一个开始。

【讨论】：

【解决方案6】：

您可以点击以下链接，非常有帮助。

Generic Repository Pattern in MVC3 Application with Entity Framework

Entity Framework and Data Patterns

【讨论】：