4

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

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

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

UnitOfWork 和服务层？

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

4

6 回答 6

3

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

如果您打算使用 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-domain 模型）实现端到端. 我会说将所有接口与具体类项目放在单独的项目中，因为接口属于客户端。这将确保客户不会直接依赖于具体的实施项目。识别 IOC 容器，使用它向其客户端注入依赖项。例如：使用 DI 将域模型注入服务层中的类。配置 DI 以在所有层中注入具体实现（服务将使用 DI 获取域模型，域模型将使用 DI 获取存储库）。如果您使用 DI，它将使您对接口进行编码，这很好。重要的是重构接口、类、方法，

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

我认为项目相当复杂。

于 2013-07-27T04:27:53.863 回答
0

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

于 2013-07-18T10:09:18.413 回答
0

您的所有问题都在“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

于 2013-07-18T12:19:16.563 回答
0

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

分层架构

依赖注入

通用存储库

带模拟的单元测试

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

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

于 2013-07-24T15:43:51.317 回答
0

请参阅有关如何创建/设置架构的答案

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

于 2013-07-25T07:53:47.643 回答
0

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

具有实体框架的 MVC3 应用程序中的通用存储库模式

实体框架和数据模式

于 2013-12-28T01:08:33.767 回答