问题标签 [unit-of-work]

在过去一周左右的时间里，我阅读了很多关于存储库模式的文章和教程。许多文章将存储库模式与工作单元模式紧密联系在一起。在这些文章中，我通常会找到类似这样的代码：

我是否正确理解工作单元对象旨在处理基础数据存储中任何对象的添加、更新或删除（在我的情况下，是我通过 LDAP 与之通信的目录服务）？如果这是真的，它不应该也处理任何对象的检索吗？为什么这不是建议的 UoW 界面的一部分？

我不确定标题是否是描述这个问题的最佳方式。

这本书 - http://apress.com/book/view/9781590599099 - 说明了工作单元模式的实现。它有点像这样。

（暂时忽略静态调用和依赖的问题）

作者指出，这种实现需要编码人员插入相关的 UoW 标记方法，并且这种对模式的选择性尊重可能会导致错误。现在，考虑到具体访问器的优缺点，您也许可以像这样自动化 UoW 调用：

所以，我的问题是，当在域对象上设置属性时，你将如何保证调用适当的 UoW 方法？

我目前正在开发我的第一个 Linq-to-Sql 应用程序。我已经实现了具有较短 dataContext 生命周期的数据访问方法，如下所示：

我想知道如何获取 clr-properties 的更改通知。当您有一个 dataContext 时，这不是问题。

所以问题是：我如何获得实体的内存变化？！

我有一个可以在两个不同屏幕中修改的实体。一个屏幕上的更新应该在另一个屏幕上可见。我看到的唯一可能性是让 dataContext 具有与两个屏幕相同的生命周期，这归结为应用程序生命周期。

我觉得工作单元模式（每个请求）和完整的数据绑定功能之间存在摩擦。请告诉我我错过了什么......

如何处理 NHibernate 方法 Flush 中引发的异常？我有一个删除对象的操作。它使用发布的 id 和调用从存储库加载对象repository.Delete(obj)。

撇开我在 NHibernate 中的映射不完整并且删除导致“DELETE 语句与 REFERENCE 约束冲突”异常不谈，这是为这种情况实现异常处理的好案例。

所以在 Flush 中抛出异常，在 UnitOfWorkPerRequestTask 中调用 Flush，这是在每个请求上创建和销毁的任务，它启动并刷新 UnitOfWork ( Rhino.Commons.UnitOfWork)。此任务使用 Windsor 容器注册，LifestyleType.Transient并由 HttpApplication 在 Begin 和 EndRequest 方法中调用。

有什么方法可以在我的删除操作中处理此异常，因此我可以注意到用户由于某些关系而无法删除此对象？

异常堆栈跟踪在这里（不完整）：

感谢帮助。

我正在使用 Ayende 的方法（http://ayende.com/Blog/archive/2009/04/29/nhibernate-ipreupdateeventlistener-amp-ipreinserteventlistener.aspx）来设置具有监听器的实体的创建和更新日期，但它只是为受影响的实体设置它们，而不是工作单元中的任何其他内容。

因此，例如，如果我这样做：

Note 获得创建/更新日期，但订单没有。是否有任何技巧可以让整个工作单元显示更新？或者我是否必须实际更新订单上的属性才能设置更新日期？

如果有什么不同，我也在使用 S#arp 架构。

这是我正在使用的代码块：

我正在处理一个设计问题，我确信它有一个简单的答案和/或以前已经解决过。很长一段时间以来，我一直在阅读、思考和寻找解决方案，但似乎没有什么是真正有意义的。

问题的要点是我正在处理一系列遗留系统和数据库，并且我正在尝试采用 DDD 方法来构建新应用程序并替换旧应用程序。核心问题是，虽然我的域实体、值对象和聚合具有商业意义，但当我考虑持久性时，我遇到了一个大问题……聚合中的实体当前持久化在多个数据库中。

例如，假设我有实体 A、B 和 C，其中 A 是聚合根。我有一个 A 的存储库，我正在围绕 NHibernate 会话使用工作单元来实现持久性。只要 A、B 和 C 都保存到单个服务器/数据库，一切都很好。但是，在我的情况下，A 和 B 可能在一个服务器/数据库上，而 C 可能保存在完全不同的服务器/数据库上。

我意识到传统智慧可能会建议一个人永远不应该这样做，但我正在处理一个遗产。当然，我可能会及时将数据层重构为更合乎逻辑的东西，但现在我被困住了。我怀疑我在某种程度上总是会遇到这个问题，我不禁想到其他人已经越过了这座桥。

简而言之，我有一个 C# 中的本土框架，包括用于持久性的 Fluent/NHibernate、用于 IoC 的 Unity，并采用标准（或至少可识别的）存储库和工作单元模式。至于数据库，我正在处理 MS SQL Server 和 Oracle。

有什么想法吗？

有可能（甚至很可能）我只是没有完全理解“工作单元”的概念。基本上，我将其视为面向对象环境中使用的一种广泛事务。启动工作单元，与对象交互，提交或回滚。但这如何分解为这些对象背后的数据存储上的实际事务呢？

在具有单个 DB 和 ORM（例如 NHibernate）的系统中，这很容易。事务可以通过 ORM 维护。但是对于一个自定义域模型掩盖了许多不同数据源的系统呢？并非所有这些数据源都是关系数据库？（这里的文件系统做了很多工作。）

现在，我坚持这样的想法：“您根本无法在同一个‘原子’业务操作中维护跨 SQL2005 DB、SQL2000 DB、DB2 DB 和文件系统的事务。” 因此，目前团队中的开发人员（通常彼此独立工作）有责任在代码中手动维护事务。每个数据库上都可以有适当的事务，但是整个业务操作在每个重要步骤中都是手动检查和平衡的。

然而，随着领域复杂性的增加和标准开发人员的流动性，这种方法将随着时间的推移变得越来越困难和容易出错。

是否有人对如何最好地处理这样的域或以前如何处理过这样的域有任何建议或示例？在这种情况下，实际的“领域”仍处于起步阶段，作为原型演变为有朝一日扩展和使用/替换由不同遗留应用程序组成的大型生态系统。因此，有足够的空间进行重新设计和重构。

作为参考，我目前针对的设计的 10,000 英尺视图是： 大量小型客户端应用程序调用基于消息的中央服务。该服务是进入“领域核心”的入口，可以被认为是一个大型 MVC 风格的应用程序。向服务发出请求（很像“动作”），由处理程序（很像“控制器”）接收。任何程序都在那里。它们与包含所有业务规则的模型交互。模型通过与存储库（数据库 x、数据库 y、文件系统、电子邮件、任何外部资源）交互来发布事件，监听器（“服务”？这部分在设计中仍然很模糊，需要改进）接收和处理。相应地，所有快乐的依赖注入。

对不起所有的冗长:) 但如果有人有任何建议，我很想听听。即使（特别是）如果那个建议是“你的设计很糟糕，试试这个……”谢谢！

我正在创建一个简单的网站来更熟悉 MVC 2.0。自 1.0 以来，我一直在做 Web 表单，并准备开始对 MVC 的 Web 表单站点进行大修。所以想要构建一个更小的应用程序来计算学习曲线。

所以我要构建一个时间跟踪应用程序。我正在使用 ASP.NET MVC 2.0 和 LINQ to SQL。我计划尝试一下存储库和工作单元，因为我将在大型网站中使用它们。

我的数据库只有 4 个表 Category、Project、Assignment 和 User。所以我将在 LINQ2SQL 中有这 4 个实体。然后我将拥有 ProjectDetails、ProjectSummary、AssignmentDetails 等的 POCO。但是那些是合并表实体吗？还是他们每个人都需要自己的存储库？还是应该将它们放入聚合存储库中？

如果您需要更多详细信息，请告诉我

谢谢

我正在考虑使用 EF 4 开始一个新项目并浏览一些文章，我发现了一篇关于 EF 的文章以及存储库模式和工作单元（http://blogs.msdn.com/b/adonet/archive/2009/ 06/16/using-repository-and-unit-of-work-patterns-with-entity-framework-4-0.aspx )

查看那篇文章，它使用 ObjectContext 作为 UnitOfWork 并将其传递给存储库。

我的问题是，如果我有 2 个 ObjectContext 怎么办，这意味着我将有 2 个工作单元，但我实际上希望在这 2 个上下文上执行的所有操作都是一个工作单元，这种情况可能吗？我不想在每个上下文中调用 save ，我希望它是事务性的 .... 不使用 transactionscope ...

例如，我有一个管理操作日志的上下文和另一个管理订单的上下文。假设在我的业务层中，我有一个名为 AddOrder() 的方法。AddOrder() 将使用订单上下文来创建新订单，但它也会使用操作日志上下文来创建新的操作日志条目。由于这些是 2 个上下文，我将不得不在两个上下文上调用 save 来提交 .... 也许唯一的选择是只有一个上下文 ....

编辑：我的意思是 2 个不同类型的上下文，例如：OperationalLogContext 和 OrderContext。

假设我的数据库中有多个数据库模式，例如：HumanRessources 和 Inventory。

在每个架构中都包含多个表。您通常将数据库拆分为多个 edmx，还是通常将所有内容都放在一个 edmx 中？

我正在考虑为每个模式创建一个 edmx，但想知道这将如何影响 unitorwork 模式。阅读一些文章，ObjectContext 将成为工作单元。通过定义 2 个 edmx，我将得到 2 个 ObjectContext：HumanRessourceContext 和 InventoryContext，这意味着每个都将是一个工作单元。如果我希望对人力资源中的实体和库存上下文中的实体进行的所有修改都是原子的，这可以通过工作单元模式实现吗？