Dav*_*vid 9 architecture soa unit-of-work
有可能(甚至可能)我只是没有完全理解"工作单元"的概念.基本上,我将其视为面向对象环境中使用的广泛事务.启动工作单元,与对象交互,提交或回滚.但是,这如何分解为这些对象背后的数据存储的实际事务？
在具有单个DB和ORM(例如NHibernate)的系统中,它很容易.可以通过ORM维护交易.但是,自定义域模型隐藏了许多不同数据源的系统呢？并非所有这些数据源都是关系数据库？(这里的文件系统已经做了很多.)
现在,我坚持认为"你根本无法在同一'原子'业务操作中跨SQL2005数据库,SQL2000数据库,DB2数据库和文件系统维护事务." 因此,目前,团队中的开发人员(通常彼此独立工作)负责在代码中手动维护事务.每个DB都可以在其上进行适当的事务处理,但是整个业务操作都是手动检查并在每个重要步骤中进行平衡.
但是,随着域和标准开发人员流动的复杂性增加,这种方法将变得越来越困难并且随着时间的推移而容易出错.
有没有人有任何关于如何最好地解决这样一个领域的建议或例子,或者之前如何处理它？在这种情况下,实际的"域"仍处于起步阶段,随着原型的发展,有朝一日扩展并消耗/替换大型不同遗留应用程序的生态系统.因此,有足够的空间进行重新设计和重新分解.
作为参考,我目前的目标是10,000英尺的设计视图:大量的小型as-dumb-as-possible客户端应用程序调用基于消息的中央服务.该服务是"域核心"的入口,可以被认为是一个大型MVC风格的应用程序.对服务进行请求(很像"动作"),由处理程序拾取(很像"控制器").任何程序都在那里.它们与包含所有业务规则的模型进行交互.模型发布的事件是监听器("服务"？这部分在设计中仍然是多云并且需要改进)通过与存储库(数据库x,数据库y,文件系统,电子邮件,任何外部资源)交互来获取和处理.所有的快乐依赖注入相应.
抱歉所有的冗长:)但如果有人有任何建议,我很乐意听到它.即使(特别是)如果这个建议是"你的设计很糟糕,试试这个......"谢谢!
Jos*_*ris 10
我之前曾在一个可以实现这一目标的系统上工作,而且相当简单.由于您的项目处于早期阶段,或许这对您来说可能是有用的信息.不幸的是,我不再能够访问代码了,但我仍然很自然地描述它是如何工作的.
我所做的是使用通用存储库模式实现构建我的存储库.基本存储库类型始终是服务和UoW的引用.为了便于讨论,我们将其称为BaseRepository."T"将仅限于IEntity实现,其表示域对象.在BaseRepository中,我创建了另一组用于合成的基类,例如SqlBaseRepository,XmlBaseRepository等.
UoW只关心某些东西属于BaseRepository类型,这是核心功能所在的位置.将表示基本CUD(CRUD),提供创建,更新和删除的等效项.每个人都会做的是创建一个委托并将其放在UoW内部的队列中,同时传递有关它将成为什么类型的事务的信息,以及完成它所需的适当数据.UoW将开始维护一个存储库需要参与事务的列表,但仍然不关心它是什么类型.有效地,在这里排队就像参与交易一样.
BaseRepository定义了一个名为.ApplyChange()的抽象方法.一旦在UoW上调用了.Commit(),它就会创建一个TransactionScope()并开始调用列表中的delagates,并将信息传递给.ApplyChange()..ApplyChange()的实际实现存在于特定的存储库库中,即SqlRepositoryBase等,并且也可以被实现覆盖.
至少对我来说,它变得棘手,它正在回归.我只处理了一个数据库,但有时会进行基于文件的更改.我添加了一个.RevertChange()方法并开始跟踪原始状态和修改状态,这样我基本上可以应用反向增量来回到我在文件堆栈上的位置.
我希望我能更具体地了解实现,但是自从我现在看到代码已经过去了一年多.我可以告诉你,原始代码的基础来自于Tim McCarthy 撰写的" .NET域驱动设计与C#:问题 - 设计 - 解决方案"一书.我的大量存储库实现基于他的示例,我的大部分定制都来自UoW及其实现.
我希望有所帮助!:-)