c# - 如何使用 Repository Pattern、Service Pattern、UnitOfWork、ORM(EF、NHibernate 等)用 ASP MVC 构建项目？

Question

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

我应该把IRepository 接口(interface)放在哪里。在 DataAccess 或单独的项目中说“存储库”？其他将扩展 IRepository<> 的抽象存储库(如 ICustomerRepository : IRepository )怎么样？他们会驻留在同一个项目中吗？ CustomerRepository : BaseRepository, ICustomerRepository

具体实现如何

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

工作单元和服务层？

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

Answer 1

不是一个明确的答案，希望能让你朝着正确的方向前进

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

这是您可以开始的图层 1)UI - 2)服务代理 - 3)服务层 - 4)领域层 - 5)Repository

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

如果您使用的是服务器端 mvc 框架(例如:asp.net mvc)之类的东西，您可能希望为每个屏幕考虑 viewmodel。由于大多数屏幕包含来自不同域模型的数据(订单详细信息 + 运输信息 + 客户详细信息在一个屏幕中)， View 模型会将所有数据合并到特定屏幕。在这种情况下，请查看 (.net) 自动映射器以在 DTO(来自服务的数据)和 View 模型之间进行映射，或者构建您自己的轻量级映射器。 如果您计划将客户端 MVC 用于 UI(例如:Angular)，那么您不需要显式设计 View 模型。无论来自服务的是什么，都将成为您的 UI 的模型。

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

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

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

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

我假设项目相当复杂。