问题标签 [unit-of-work]

我需要一些建议，我们如何在表示层中解耦 nHibernate 依赖项。目前我们有一个三层 C# winforms 应用程序，由以下层组成（简化）；

• 用户界面 (UI)
• 业务逻辑 (BAL)
• 数据访问逻辑 (DAL)

我们正在将此应用程序迁移到 ORM (nHibernate)，理想情况下希望只有 DAL 引用 nHibernate。我们还希望使用 nHibernate 中包含的“工作单元”功能，采用“会话每个会话”方法。

为了实现这一点，我们需要在 UI 中创建并打开一个会话，将会话通过 BAL 传递给 DAL，但是如果不在 BAL 和 DAL 中创建对 nHibernate 的依赖项，我们就无法实现这一点。

任何意见，将不胜感激。我们应该如何构建架构以避免在 UI 和 BAL 中对 nHibernate 的任何引用。有任何想法吗？

我还必须补充一点，我们也不希望 UI 引用 DAL。

UI => BAL => DAL

在 DDD 模式中，工作单元是否应该与存储库耦合？我见过几个不同的例子，包括实现工作单元接口的存储库，实现工作单元本身行为的存储库，以及具有表示工作单元的属性的存储库，以便可以跨UoW 生命周期中的多个存储库实例。在后者的情况下，这似乎是一种反模式......也就是说，消费者是否真的需要知道在存储库实例之间共享 UoW 的实例？那不应该被封装并且不暴露给消费者吗？

我想听听一些关于这些不同方法的优势以及原因的意见。

谢谢。

在 Asp.Net MVC 应用程序中我应该在哪里调用Commit()我的 UnitOfWork？并且仍然保持我的控制器单元可测试。

我使用 HttpModule 吗？创建一个基本控制器并使用OnActionExecuted？或 Global.asax: Application_EndRequest()?

简单的问题。

如何将 UnitOfWork 与 Castle.Windsor、nHibernate 和 ASP.NET MVC 一起使用？

现在了解详细信息。在我寻求理解该UnitOfWork模式的过程中，我很难遇到任何使用直接示例与 结合使用的东西Castle.Windsor，特别是关于它需要安装的方式。

到目前为止，这是我的理解。

工作单位

• 该IUnitOfWork接口用于声明模式
• 类UnitOfWork必须Commit和Rollback事务，并暴露一个Session。

话虽如此，这是我的IUnitOfWork. （我正在使用Fluent nHibernate）

所以这是我的Castle.Windsor容器引导程序（ASP.NET MVC）

所以现在，在我的Global.asax文件中，我有以下...

存储库

现在我明白我需要将 传递ISession给我的存储库。那么，让我假设IMembershipRepository。

所以我现在很困惑。使用这种方法，ISession不会被正确销毁，并且UnitOfWork永远不会被使用。

我被告知UnitOfWork需要进入 Web 请求级别 - 但我找不到任何解释如何实际执行此操作的内容。我不使用ServiceLocator任何类型的（当我尝试时，有人告诉我这也是不好的做法......）。

困惑——如何UnitOfWork创建一个？

我只是不明白这一点，一般来说。我的想法是我将开始传递UnitOfWork给 Repository构造函数 - 但如果它必须进入 Web 请求，我不明白两者之间的关系。

更多代码

这是用于澄清的额外代码，仅仅是因为我似乎有从不为我的问题提供正确信息的习惯。

安装人员

工作单位

这是我的UnitOfWork课堂逐字记录。

我正在按照工作单元模式制作一个界面。我的界面如下所示：

到现在为止还挺好。现在我在我的数据层中实现它，它使用 EF4 作为数据提供者。我为“查询”方法想出了这段代码，但我认为它不是很干净，我觉得有一个聪明的方法可以做到，但我真的想不通。

我在这里看到的问题是所有 IF 每次都经过测试，尽管我可以将它们链接在级联的 if-else 中，但对我来说仍然看起来很糟糕。另一个问题是我必须为每个可能添加的新实体手动添加一行，但这不是我主要关心的问题。

有人对此有什么好的建议吗？谢谢。

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

以一种方式比其他方式有什么好处吗？如果有共识，共识是什么？

背景

据我了解，工作单元 (UoW) 模式本质上提供了事务语义。换句话说，给定一个由存储库持久化的聚合域，UoW 类允许域的消费者将存储库方法的调用注册到原子操作中。假设我们有：

假设IRepository使用关系数据库的实现，并且IUnitOfWork.Commit仅与数据库建立事务并继续为已注册的所有操作调用Save或Remove在适当的实例上进行。IRepository我想说我上面概述的是对聚合根、存储库和 UoW 模式的标准、直接解释（尽管 NHibernate/EF 和所有它们臃肿的荣耀）。

过去，我将聚合根边界的概念解释为，从一个聚合到另一个聚合的引用应该由源聚合上目标聚合的 Id 属性客观化。例如：

问题

鉴于上述关注点的分离和聚合边界的解释，如何为需要在事务上创建聚合并将其存储库生成的 Id 保存在另一个聚合中的消费者提供事务支持？例如，我怎样才能创建一个User和一个Blog事务性Blog.UserId设置为User.Id？

我想出了一些答案（标记为社区 wiki），但无论如何我都会在这里发布我的问题以征求反馈和更多答案。

据我了解，UnitOfWork 类旨在表示域中业务事务的概念。它不应该直接代表数据库事务，这只是一种可能实现的细节。

问：那么为什么这么多关于工作单元模式的文档都提到“提交”和“回滚”方法？

这些概念对领域或领域专家毫无意义。业务事务可以“完成”，因此 UnitOfWork 应该提供“完成”方法。同样，不应该将其建模为“清除”而不是“回滚”方法吗？

更新：

答：以下两个答案都是正确的。它们是 UoW 的两个变体：对象注册和调用者注册。在对象注册中，回滚用于撤消对所有内存对象的更改。在调用者注册中，回滚用于清除所有记录的更改，以便后续调用 Commit 将不会执行任何操作。

我已经用我的实体框架存储库实现了一个工作单元模式。**打高尔夫球**

现在我想知道在同一个提交中进行多个插入和/或删除的常见做法是什么？

例如：想象一下，我希望添加 5 个新对象/实体，出于某种原因，现在删除实体 #3。

这会起作用吗..就像..应该添加实体然后从数据库中删除1？或者这只会发生在 EF 实体列表中？

这是不好的做法吗？IE。永远不要将添加/更新与删除混合在一起？总是在删除之前提交？

我正在尝试建立一个使用 UnitOfWork 和存储库模式的项目。

现在我不能使用 IoC 和 EF4，所以我正在尝试使用 Linq 和具有一点依赖性的 DataContext :(。我不掩饰我对所有这些概念的集成有点困惑。我注意到调试我的代码，DataContext 没有看到对对象所做的更新，但每次它都会向数据库添加一个新实体。

我已经阅读了很多，但我找不到我的问题，也许这是一个简单的步骤。在我继续之前，这就是我所拥有的：

例如，我有一个名为 foo 的对象...我有一个 foo 控制器，它在构造函数中创建了一个新的 fooRepository 实例。在 fooRepository 中，我添加了对包含 DataContext 的 UnitOfWork 的引用......对吗？这是我的代码

任何帮助或建议将不胜感激！

抱歉，如果我发布了所有代码，但是大约一周后，我会为这件事发疯。