分层后xxO的困惑

04-07-09 licy

现在java开发中存在好多名词啊：
PO - persistence object(CMP、BMP可归与此)
VO - value object
DTO - data transfer object
BO - business object
POLO - Plain Old Java Object
detached PO ...

还有
View Object, 界面展现需要的对象，如Struts的FormBean

那么多xxO，只会把系统复杂化，增加理解、维护系统的困难度。
也许Java在不断进步吧，当EJB 2.0出来的时候，Core j2ee Patterns中的Composite EnityBean就失去了意义，也许EJB 3.0出来的时候，DTO等也就失去了意义。
如果以后使用了采用POJO的模型的EJB 3.0，问题是不是会简单了很多呢。

不过目前还是有些问题比较困惑。
如果分层的话，
对于前台界面，业务层，还有持久层，其需要的数据可能是不同的。

假若前台界面对应FormBean,业务层对应BO或者VO,而持久层对应PO.
那么当有些字段在BO中存在（而业务层不一定每次都处理这些字段，只是在有需要的时候处理)，而在FormBean中不存在。
当在前台界面查询到数据并修改的时候，如果jsp页面里面不存在对应的表单对象，生成的FormBean里面也没有这些字段的数据，然后FormBean的值传递给了BO，再有BO传递给PO进行数据库更新工作。期间这些本来有值的字段自从页面提交后就一直没有了值，更新丢失了。

目前我的解决办法是，FormBean包含BO中的所有字段，当数据库中的数据传到FormBean对象后把对象缓存起来，当struts生成FormBean的时候，再根据页面里面有的表单对象更新缓存起来的那个FormBean,感觉很复杂。

假如用HashMap记录更新的字段？好象工作量增加了不少。

不知道大家都是如何处理的，谢谢

juzcn

2004-07-10 09:54

困惑总是会有的。我的立即是这样的。

1）所有的O都是O
2) 理解设计者的意图，探索最佳实践
3) 例如：在EJB的理论中，除了EntityBean有set方法，而VO是不建议有set方法，否则会有缓存的不一致；BO是没有永久特性，因此大多数是无状态的，不要使用BO去映射实体对象，那只是业务逻辑。

banq

2004-07-12 10:33

不管什么O，J2EE主要分三种类型：首先是Model，依次在表现层和持久层实现是Form 和Entity Bean

licy

2004-07-12 12:00

这个还用说啊,我的意思是在不同层之间的数据转换需要做很多工作，很头疼。

banq

2004-07-12 12:10

Model是接口性质的，如果你的系统是面向Model设计，不是面向数据库设计，那么你所说的头疼问题就轻多了。

但是，如果Model变化了，会涉及很多层面的变化，这是没有办法的，因为需求总是变化的，只有通过框架来减少各层面的变化。