MVC和EF解决方案结构 - 您应该使用存储库模式，服务定位器还是两者？

Question

采用具有以下应用程序的方案：

• MVC 4 Web App
• 应用程序通过Entity Framework 5与现有数据库进行通信 （没有计划更改为另一个ORM或数据库平台）。
• 该应用程序与外部SOAP Web服务（Web服务 可能会更改为WCF）。

你愿意：

1. 为所有EF实体创建通用存储库（例如 MyDBRepository），以及SOAP Web Services调用的存储库 （例如MyWSRepository）。然后创建一个包含的服务类 业务逻辑使用两个存储库来访问数据和 为所有控制器的需求实现CRUD方法 （MyApplicationService）。然后注入存储库 服务类，最后注入的服务类 MVC控制器。

2. 或者你有一个服务类来处理数据库查询和 业务逻辑使用EF生成的DBContext并生成 表实体（例如MyDBService）和另一个服务类 处理业务逻辑和SOAP Web服务调用（例如 MySOAPWebService）。然后将两个服务注入MVC 控制器。

3. 或其他。

在过去，我使用过选项1.但我想知道这是否只是添加了不必要的抽象层。如果实体框架生成DBContext，则直接使用DBContext实体的服务类似乎不那么复杂。

通过阅读StackOverflow中的几篇文章和其他问题，似乎有一条灰色线区分了服务定位器模式和存储库模式。

您会使用哪种结构？

Answer 1

我建议为每个聚合使用存储库或DAO。使这些类在构造函数（或工作单元，如果您愿意）上接收dbContext。

然后让您的服务实现业务逻辑并使用DAO。该服务负责实例化DBContext（如果需要，则为事务）。然后，服务使用相同的上下文调用不同的DAO。

对于更强大的解耦，我强烈建议您使服务层无法触及DBContext。强迫自己每次都要经历DAO。

服务层还应该处理异常。在我的应用程序中，服务层只抛出两种类型的异常：用户和系统。在控制器上，我使用它们来区分可恢复的错误或其他内容。 （这就是为什么你有时会看到诸如“无效订单号”之类的特定错误或其他类似“系统中发生错误，稍后再试”的原因。）

顺便说一句，永远不要忘记使用断开连接的实体。当您调用存储库进行添加/更新时，始终假设POCO已断开连接并相应地使用它们。