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

Question

以您有以下应用程序的场景为例：

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

你会：

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

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

3. 或者别的什么。

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

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

你会使用哪种结构？

Answer 1

我为每个聚合推荐一个存储库或 DAO。让这些类在构造函数（或者你喜欢的工作单元）上接收 dbContext。

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

为了更强大的解耦，我强烈建议您让服务层无法接触 DBContext。每次都强迫自己通过 DAO。

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

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