论坛首页 Java企业应用论坛

也谈领域对象的数据与动作分离

浏览 7322 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2008-08-08  
说来惭愧, 某日项目组成员交上来领域模型类图,将对象的属性和方法分类,基本上统统使用了DomainObject-DomainObjectManager的方式,前者之后属性以及对应的getter-setter方法,后者包含具体的业务操作.在我询问为什么要这么做的时候,对方反问为什么不能呢,我说这样不符合OO,OO的对象是具有属性已经在此属性上具有操作能力的一种东西,他说分开来一部分用作PO对应数据库表,动作部分用来做基本业务处理难道不好吗? 我一时语塞...只能饮用Robin的一段:
引用
首先要区别持久对象和POJO。

持久对象实际上必须对应数据库中的entity,所以和POJO有所区别。比如说POJO是由new创建,由GC回收。但是持久对象是 insert数据库创建,由数据库delete删除的。基本上持久对象生命周期和数据库密切相关。另外持久对象往往只能存在一个数据库 Connection之中,Connnection关闭以后,持久对象就不存在了,而POJO只要不被GC回收,总是存在的。

由于存在诸多差别,因此持久对象PO(Persistent Object)在代码上肯定和POJO不同,起码PO相对于POJO会增加一些用来管理数据库entity状态的属性和方法。而ORM追求的目标就是要 PO在使用上尽量和POJO一致,对于程序员来说,他们可以把PO当做POJO来用,而感觉不到PO的存在。



难道这就是传说中的贫血Domian  Model,而所谓的Service其实就是这些个Manager的集合?



  • 大小: 32.9 KB
   发表时间:2008-09-17  
有同感,现在身边有很多同事也是这样考虑、设计模型的。把行为、状态分离到一组类中,而将操作的数据(一时也含状态)都放在另外的一组类中,就如上面的图中那样。一些同事还把这种情况和MVC结合,当然了他是把MVC当成了架构模式来看的,实际上MVC是表示模式。说M主要是负责数据加工的(行为对象),而数据对象则统统为了M和V通信,做为被加工的对象。

现在也有些困惑,感觉这样也OO是违背的,但当大家问到为什么不能这样设计时也很难和其解释。
另外还有重要一点,我感觉这和模型所在的业务有关,觉得做MIS业务很容易就形成这样的设计。而如果做一些框架、工具则不太可能这样这种情况。

和大家探讨。
0 请登录后投票
   发表时间:2008-09-17  
其实这样做也很好呀,本来就没血,干嘛非要脑充血?OO不OO不是教条
0 请登录后投票
   发表时间:2008-09-17  
为什么要把Domain Object和DomainObjectManager对应起来?太死板了。

你把Domain Object理解成你系统中所有的管理对象,把所有的Manager理解成你系统所有的对外接口就可以了。所谓的Manager或者Service是一组可进行系统操作的接口集合,而不是机械性的对Domain Object进行CRUD的操作。
0 请登录后投票
   发表时间:2008-09-17  
Manager和Service其实是两层 如果硬要搅在一起就更加不OO了

把Domain Object和DomainObjectManager看成一个整体

有点类似于bridge模式 service是更上一层的东西
0 请登录后投票
   发表时间:2008-09-18  
这是老问题了,可以概括为  Domain Model 和 Transact Script 两种企业级模式的区别。 Martin Fowler 曾在这个问题上说了很多口气很大的话,却没什么说服力。总之这个问题还在争论中,还没争出什么结果。我个人偏向 Transact Script模式,因为我觉得把 持久化做得完全透明,本来就是很危险的事情,而且设计者在心理上也不需要这种透明。
0 请登录后投票
   发表时间:2008-09-19  
finalbone 写道
Manager和Service其实是两层 如果硬要搅在一起就更加不OO了

把Domain Object和DomainObjectManager看成一个整体

有点类似于bridge模式 service是更上一层的东西

这个话有点不理解,那Mgr里面包含的是些什么东西?bridge的设计模式在Spring中不就是将抽象的业务逻辑(service)和真正操作数据的实现(DAO)分开吗?

那楼主认为有问题的东东问题有在哪里呢?
0 请登录后投票
   发表时间:2008-09-19  
是不是充血的鸡翅就能比贫血的鸡翅卖得更好价钱?

不能的话没事干嘛折腾自己,统统贫血,不是简单又美味吗?
0 请登录后投票
   发表时间:2008-09-19  
答:因为企业级的Web+业务逻辑+数据库应用不适合OO。
为什么这样说呢?一个数据模型是对一套业务的完整抽象,因此数据库是业务系统的骨干。不幸的是,当前流行的数据库是关系型数据库而非OO数据库,这就造成了整个架构上的不匹配。所以从整个系统的架构上来说,并非OO,包括PO和DAO在内的方法,元素都是借用了一个OO语言描述一个非OO的语意。因此不应强制一定要OO,可以在实现具体业务时借用OO,但整个架构上并非如此。
0 请登录后投票
   发表时间:2008-09-19  
在MIS中的“构件”通常就是包括属性和操作,例如“入库单”。形成构件库,不知用这种方式如何组织??
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics