在服务层或存储库层管理事务？
我有一个特定的场景，其中基于某些约束在多个表上完成插入和更新。因此很自然地在这些场景中使用事务范围。现在，我有一个存储库层和一个服务层。服务层调解存储库和 UI，并且始终处于无知状态。 现在我很困惑在服务层或存储库层中的何处使用事务。我没有使用任何 ORM。我还看到人们提倡针对此类场景使用工作单元模式。有没有适合我当前场景的工作单元模式示例，我见过的所有示例都使用 ORMS。
谢谢，
I have a certain scenario where inserts and updates are done on multiple tables based on some constraints ..so its natural to use Transaction scope for these scenarios.Now,I have a respository layer and a service layer. service layer mediates the repository and the UI and is persistent ignorant.
Now i m confused where to use the transactions either in service or in repository layers.I am not using any ORMs. I have also seen people advocating about Unit of work pattern for such scenarios. are there any examples about unit of work pattern that suits my current scenarios,all the examples i have seen are using ORMS.
Thanks,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
当然，这取决于您的系统，但通常我会在服务层中执行此操作。特别是如果您的服务层方法调用多个细粒度存储库方法并期望它们全部提交或全部回滚。
This is going to depend on your system of course, but typically I would do it in the service layer. Especially if your service layer methods call multiple fine-grained repository methods and expect them to either all commit or all rollback.
一些可能有助于回答这个问题的问题。
哪一层理解事务需求？
您的存储库界面的粒度是多少？
在我的世界中，我们倾向于进行细粒度的持久性操作，插入、更新、删除。然后将它们组合在服务层中。因此，在这种环境中，对我来说显而易见的是，服务层理解事务范围。
Some questions that may help answer this.
Which layer understands the transactional requirements?
What is the granularity of your repository interface?
In my world we tend to have fine-grained persistence operations, Insert, Update, Delete. and then compose them in the service layer. Hence in this environment it seems obvious to me that it's the service layer which understands the transactional scope.