2

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

  • Web（参考 ViewModels 和 Controllers）
  • 视图模型
  • 控制器
  • 服务（参考数据和实体）
  • 数据（参考实体）
  • 实体

我想要实现的是“UnitOfWork”模式，因此我有一个由 DI 为该工作注入的类，当我完成时，可以在控制器的 actionresult 中执行 .commit()数据库。

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

4

3 回答 3

5

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

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

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

工作单元做两件事：

  1. 有Commit()方法
  2. 将基础对象/实体集公开给存储库。

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

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

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

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

于 2011-02-08T20:59:47.250 回答
0

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

于 2011-02-08T20:38:39.340 回答
0

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

于 2011-02-08T20:46:47.750 回答