ASP.NET MVC - 使用UnitOfWork

Question

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

• Web（对ViewModels和Controllers的引用）
• 的ViewModels
• 控制器
• 服务（对数据和实体的引用）
• 数据（对实体的引用）
• 实体

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

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

Answer 1

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

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

1. 工作单元源自实际的底层上下文（DataContext - L2SQL，ObjectContext / EF）
2. 存储库需要一个工作单元。

工作单元做两件事：

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

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

1. 控制器获得DI服务和工作单元（均通过接口）
2. 控制器调用服务上的方法（“CustomerServices.AddOrder（）”）
3. 存储库上的服务调用方法
4. Repository在“Order”对象/实体集
上调用“Add”方法
5. 控制器提交工作单元

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

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

HTH。

Answer 2

Answer 3

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