san*_*ole 5 nhibernate domain-driven-design dependency-injection castle-windsor ioc-container
我正在比较从域模型使用服务(在Windsor IoC容器中的进程本地组件的意义上)的可能性.
我有3种方法来实现这个目标:
发布域事件并使用服务层代码处理它
通过模型对象上的方法注入服务
在模型对象中注入服务
(4.使用服务定位器)
第一个导致一个非常富有表现力和重复性的模式,为过程简单的任务创建一个过程风格的域事件和处理程序.但它具有最佳的模型与其所使用的环境的解耦(模型是自定义的).
第二个使方法参数更长并且看起来破坏了封装(如果模型对象的动作需要其他服务,则所有调用者都必须更改).
第三个将注入当前事务不需要的依赖项.此外,还需要"扩展"NHibernate.由于其他推荐阅读,我会避免这种方法.
由于我想在我们的文档中写这个,我需要告诉读者何时使用哪种方法.我正在思考"使用方法注入,如果你将域事件处理程序放入模型程序集"这一行,但它并没有真正达到目的.
对此规则的建议？
如果AR(聚合根)需要来自服务的某些数据,那么该数据应被视为依赖(不是服务).基本上,AR根本不会知道该服务.
如果某个方法确实具有在构造函数中注入没有意义的depednency,则将其作为方法参数传递.我不认为你应该通过服务(但它取决于),直接传递所需的数据.
如果AR做了一些需要服务来更新内容的东西,我认为消息驱动是要走的路(生成一个事件).
关于NHibernate或其他细节,AR不需要了解它们.如果它不是域概念,请远离AR.
就个人而言,我尝试对AR进行建模,以便它不需要服务.在场景中涉及多个AR,我将使用具有可靠服务总线的域事件.这意味着任何db事务都是不可能的.我只在AR中保留事务性内容,更准确地说是在AR存储库中,因为其他所有内容都是最终的一致性.
| 归档时间： |
|
| 查看次数： |
227 次 |
| 最近记录： |