EF4 - 存储库和工作单元

发布于 2024-10-10 01:47:27 字数 168 浏览 5 评论 0原文

我一直在寻找将存储库和工作单元集成到我的项目中的“正确”方法,但我一直在尝试不同的变体。有些将存储库作为 uow 对象的成员。其他人拥有实现 IUnitOfWork 接口的存储库。我见过一些 uow 对象作为构造函数的参数传递到存储库中的情况。

采取一种方式比其他方式有什么好处吗?如果有的话,共识是什么?

I've been searching for the 'right' way to integrate repositories and unit of work into my project, yet I keep running across different variations. Some have the repositories as members of a uow object. Others have the repositories implementing an IUnitOfWork interface. I've seen some where the uow object is passed into the repositories as an argument to their constructors.

Is there any benefit to doing it one way over the others? What's the consensus, if there is one?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

情丝乱 2024-10-17 01:47:27

我不能说已经达成共识,但除了我与许多建筑师讨论过这个话题之外,我还花了相当多的时间来评估这件事。我的想法是,您希望保持对象管理(存储库)和事务(工作单元)松散耦合且彼此独立。您的存储库应该能够运行而无需使用事务,反之亦然。就其与存储库的关系而言,工作单元实际上只是事务的包装器。在您的情况下,您可能会使用 TransactionScope 实现来包装 EF2 存储库操作。在我们的框架中,我们将事务管理放入 DataServices 命名空间/项目中,并将基本存储库类放入 ObjectAccess 命名空间/项目中。从那里,我们为存储库操作和工作单元操作创建了 EF2 实现。我无法给你来源,但基本上我所做的是以下内容:

  • 使用 NCommon 1.1 Beta 作为我的起点: NCommon
  • 将工作单元与 NCommon 中的存储库操作分离
  • 然后我继续讨论如何管理我的 ObjectContext。

我们即将发布该框架的第一个稳定版本。祝你好运!

I can't say that there is a consensus out there, but on top of my having spoken to many architects about the topic, I have spent a considerable amount of time evaluating this very thing. What I've come up with is that you want to keep your object management (Repositories) and transactions (UnitOfWork) loosely coupled and independent of each other. Your Repository should be able to run without having to use a transaction and vise versa. In terms of its relation to a Repository, a Unit of Work is really just a wrapper for a transaction. In your case, you will probably be wrapping EF2 Repository operations using the TransactionScope implementation. In our framework, we've put transaction management into a DataServices namespace/project and our base Repository classes in an ObjectAccess namespace/project. From there we created an EF2 implementation for both the Repository operations and the Unit of Work operations. I can't give you the source, but basically what I did was the following:

  • Used NCommon 1.1 Beta as my starting point: NCommon
  • Decoupled the Unit of Work from the Repository operations in NCommon
  • Then I moved on to how my ObjectContext would need to be managed.

We are just about to release our first stable version of this framework. Good luck!

天冷不及心凉 2024-10-17 01:47:27

鉴于以下几页,我想说 MS 的共识是 UnitOfWork 公开存储库:

http://www.asp.net/entity-framework/tutorials/implementing-the-repository-and-unit-of-工作模式in-an-asp-net-mvc-application

http://msdn.microsoft.com/en-us/library/ff714955.aspx

两者似乎都是微软的指导,而不是一个人的简化博客文章示例。

Given the following pages I'd say that the MS consensus is UnitOfWork exposing repositories:

http://www.asp.net/entity-framework/tutorials/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

http://msdn.microsoft.com/en-us/library/ff714955.aspx

Both seem to be MS guidance, rather than being 1 guy's simplfied blog post example.

赠我空喜 2024-10-17 01:47:27

没有“正确”的方法来做到这一点。找到适合您情况的实现并使用它。我个人喜欢让事情变得简单,所以我通常只在我的所有项目中使用通用存储库(根本没有 UoW 接口/模式)。

There is no 'right' way to do it. Find an implementation that works for your situation and use it. I personally like to keep things simple so I usually just go for a generic repository in my all projects (no UoW interface/pattern at all).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文