ASP.NET MVC - 使用UnitOfWork

ebb*_*ebb 2 asp.net asp.net-mvc separation-of-concerns unitofworkapplication

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

  • Web(对ViewModels和Controllers的引用)
  • 的ViewModels
  • 控制器
  • 服务(参考数据和实体)
  • 数据(参考实体)
  • 实体

我正在尝试实现一个"UnitOfWork"模式,因此我有一个由DI为该作业注入的类,这使得在我完成时可以在控制器的actionresult中执行.commit()数据库.

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

RPM*_*984 5

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

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

  1. 工作单元源自实际的底层上下文(DataContext - L2SQL,ObjectContext/EF)
  2. 存储库在他们的ctor中占用一个工作单元.

工作单元做两件事:

  1. Commit()方法
  2. 将底层对象/实体集暴露给存储库.

完成所有设置有点棘手,但是一旦完成,流程应如下所示:

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

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

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

HTH.