ASP.NET MVC - 使用 UnitOfWork
我目前正在开发一个由 6 层组成的 Web 应用程序：
- Web（参考 ViewModels 和控制器）
- ViewModels
- 控制器
- 服务（参考数据和实体）
- 数据（参考实体）
- 实体
我想要的是实现一个“UnitOfWork”模式，因此我有一个由 DI 为该作业注入的类，这使得当我完成数据库操作时可以在控制器的 actionresult 中执行 .commit() 。
现在我的问题是……这个 UnitOfWork 类应该放在哪里？目前它在我的数据层中，但需要控制器层引用数据层和服务层，这在我看来很奇怪......我应该将 UnitOfWork 类/接口移至服务层并使用 DI 吗？
I'm currently working on a web app which consist of 6 layers:
- Web (reference to ViewModels and Controllers)
- ViewModels
- Controllers
- Services (reference to Data and Entities)
- Data (reference to Entities)
- Entities
What I'm trying to is to implement a "UnitOfWork" pattern, and therefore I have a class thats injected by DI for that job which makes it possible to do .commit() in the actionresult in the controller when I'm done with the database.
Now is my question... Where should this UnitOfWork class be placed? It's at the moment in my Data layer but that requires the Controller layer to reference the Data layer AND the Service layer, which is odd in my opinion... Should I move the UnitOfWork class/interface to the Service layer and use DI?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
除非您在数据层中使用存储库模式，否则您就是在浪费时间。
UoW 的要点是处理跨多个存储库实例的更改，这是通过以下方式完成的：
工作单元做两件事：
Commit()方法完成所有设置有点棘手，但是一旦完成，流程应该是这样的：
本质上，每个层在其构造函数中采用“下一层”的实例。 一切都应该是DI'ed和界面驱动的。 UoW 不依赖任何东西 - 但存储库依赖它来持久保存“内部存储器”(ORM)，然后 UoW“Commit”会将更改推送到数据库（基本上包装了“SaveChanges”方法）。
由于工作单元是基础设施/持久性/数据库/事务问题，因此它应该进入您的数据层。只能由控制器引用。
Unless you're using the Repository pattern in your Data layer, you're wasting your time.
The point of a UoW is to handle changes across multiple Repository instances, this is done in the following ways:
The Unit of Work do two things:
Commit()methodIt's a little tricky to get it all setup, but once you do, the flow should be like this:
Essentially, each layer takes an instance of the "next layer" in their constructor. Everything should be DI'ed and interface-driven. The UoW has not reliance on anything - but the Repository relies on it for persistence to the "internal memory" (ORM), then the UoW "Commit" will push the changes out to the database (basically wraps the "SaveChanges" method).
As the Unit of Work is an infrastructure/persistence/database/transactional concern, it should go into your Data layer. Should only be referenced by Controllers.
我实现了
IUnitOfWork类，将其直接传递到我的 MVC 控制器（通过 Castle Windsor 注入）。然后我让控制器将其传递给它实例化的任何服务对象。I implemented my
IUnitOfWorkclass to be passed directly into my MVC controllers (injected via Castle Windsor). I then have my controller pass it to any service objects it instantiates.IUnitOfWork 应该是数据层的接口。当请求进入控制器然后调用服务方法，如果您需要 CRUD，则应该调用 UnitOfWork。您可以通过在 Global.asax Request_Start 中调用 UnitOfWork 并在 Request_End 中提交工作来使用每个请求的会话。
IUnitOfWork should be an interface for data layer. When request come into Controller then call service methods, if you require CRUD there should call UnitOfWork. You may use Session Per Request by call UnitOfWork in Global.asax Request_Start and commit works in Request_End.