ASP.NET MVC - 使用 UnitOfWork答案

【问题标题】：ASP.NET MVC - Using UnitOfWorkASP.NET MVC - 使用 UnitOfWork
【发布时间】：2011-02-08 20:30:28
【问题描述】：

我目前正在开发一个由 6 层组成的网络应用程序：

Web（参考 ViewModel 和控制器）
视图模型
控制器
服务（参考数据和实体）
数据（对实体的引用）
实体

我正在尝试实现“UnitOfWork”模式，因此我有一个由 DI 为该工作注入的类，这使得当我在控制器的 actionresult 中执行 .commit() 成为可能我完成了数据库。

现在我的问题是……这个 UnitOfWork 类应该放在哪里？目前在我的数据层中，但这需要控制器层引用数据层和服务层，这在我看来很奇怪......我应该将 UnitOfWork 类/接口移动到服务层并使用 DI 吗？

【问题讨论】：

标签： asp.net asp.net-mvc separation-of-concerns unitofworkapplication

【解决方案1】：

除非您在 Data 层中使用存储库模式，否则您就是在浪费时间。

UoW 的重点是处理跨多个 Repository 实例的更改，这是通过以下方式完成的：

工作单元派生自实际的底层上下文（DataContext - L2SQL、ObjectContext/EF）
存储库在其 ctor 中采用一个工作单元。

工作单元做两件事：

有一个Commit() 方法
将基础对象/实体集公开到存储库。

完成所有设置有点棘手，但一旦完成，流程应该是这样的：

控制器获取了一个服务和一个工作单元（都通过接口）
控制器调用服务上的方法（“CustomerServices.AddOrder()”）
Repository 上的服务调用方法
存储库在“订单”对象/实体集上调用“添加”方法
控制器提交工作单元

本质上，每一层都在其构造函数中采用“下一层”的实例。一切都应该是 DI 和界面驱动的。 UoW 不依赖任何东西 - 但存储库依赖它来持久保存到“内部存储器”（ORM），然后 UoW“提交”会将更改推送到数据库（基本上包装了“SaveChanges”方法）。

由于工作单元是基础架构/持久性/数据库/事务性问题，它应该进入您的数据层。应该只被控制器引用。

【讨论】：

没错！ - 这就是它的工作原理......但我只是想知道在哪里放置 IUnitOfWork（哪一层？）
@ebb - 数据层。这是一个基础设施/数据问题。
@RPM1984 - 但这会让我的控制器层同时引用服务层和数据层？
@ebb - 实际上我收回了。我的 UoW 在“普通”程序集中。诸如常见的 LINQ 扩展方法、通用存储库接口/抽象类和工作单元接口之类的东西。因此，您的控制器引用了“通用”程序集，并且实现包含在您的“数据”程序集中 - 通过 DI 配置。如果这有意义的话。
它确实......但是将通用存储库接口作为“通用”程序集的一部分 - 这不是太多，因为它只与服务层有关吗？ - 我确实看到给 UoW 提供自己的程序集是个好主意，但话又说回来......有一个“通用”程序集，其中包含仅应在 1 层（以及声明的层）中使用的东西 -在我看来是“过度分离”。

【解决方案2】：

我实现了我的 IUnitOfWork 类以直接传递到我的 MVC 控制器（通过 Castle Windsor 注入）。然后我让我的控制器将它传递给它实例化的任何服务对象。

【讨论】：

【解决方案3】：

IUnitOfWork 应该是数据层的接口。当请求进入控制器然后调用服务方法，如果你需要 CRUD 应该调用 UnitOfWork。您可以通过在 Global.asax Request_Start 中调用 UnitOfWork 来使用 Session Per Request 并在 Request_End 中提交作品。

【讨论】：

但是 UnitOfWork 的全部意义在于使其独立于服务层。服务应该只知道数据层。所以 service = add/delete/update, Controller = .commit() 中的 ActionResult 一次刷新所有操作以减少访问数据库的次数。
您的服务层不依赖于 UnitOfWork，但应该依赖于包含 IUnitOfWork 的接口层