发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 大数据 扩展性 并发编程 事件驱动 分布式 SOA
1 2 3 4 ... 8 下一页 Go 8

ValueObject和DTO模式的一些疑问

              
2005-11-11 09:49
赞助商链接

ValueObject和DTO模式是常用的J2EE设计模式,模式所体现的不仅仅是一个设计技巧,更主要的是数据封装的思想。最近我在做设计的时候却对这个模式产生了一些疑问。
1. 对于位于持久层中的ValueObject,我是否应该限制他们的使用范围?以Hiberante为例,由于ValueObject的生命周期的特性,我们不能把他们当作DTO在层间传递。但是,如果使用BeanUtils等工具复制一个的话,却总是感觉有些浪费内存。如果是EntityBean则没有这些疑问――很显然我不能把EJB Bean实例当作DTO在层间传递――浪费就浪费吧。
2. 表现层的表单也需要对象封装,在Struts中就是FormBean,但是在JSF中却没有这样的概念,这样一不小心我们就容易在表现层直接使用model中的对象,这也是不合理的。
3. Business层需要处理从表现层传入的数据对象,这个数据对象也不能是FormBean或其他表现层VO,因为往往这些表现层VO直接反映的是表单数据,例如一个String格式的日期或者confirmedPassword,前者需要转化为Date类型而后者则在Business层用不到,这些处理也应该在表现层处理(?)。
4. DAO层接收Business层的数据,这个数据应是Business层对表现层数据的处理结果。
这样一来,我们在处理一个case的时候就出现了3个ValueObject:
 一个是表现层的用于反映页面数据。
 一个是Business层的,用于作为表现层和Business之间的DTO。
 另一个是Domain&DAO层的,用于持久化的ValueObject。
这真是浪费呀!
我的疑问是,我是否可以省略其中的一个或多个?还是根据不同情况和需求灵活处理,各位大虾是如何做的?

1
2005-11-11 10:11

我一般是用一个来传递的,我主要是觉得封装太麻烦,包来拆去的。
你可以参考一下我以前的一篇贴子,好像是jsp 传2维数组。
这样做的缺点就是和面向对象的思想有些脱离,及每个对象,对业务的反映能力不强。
其实,这也是架构时常用的一种"模糊"技巧。只有模糊了,才能既是a 也是b,才能重用。具体实现中,我的手段主要是,接口,参数,弹性域,当然向上还有框架。

2005-11-11 10:28

DTO模式就是ValueObject模式,DTO是后来更名的,这在TSS首页的EJB模式或SUN的J2EE核心模式中有过说明。

2005-11-11 10:36

>DTO模式就是ValueObject模式,DTO是后来更名的,这在TSS首页的EJB模式或SUN的J2EE核心模式中有过说明。
这些说明也不一定准确,值对象模式主要考虑的是数据封装,而数据传送对象则考虑数据层间传递的方法,二者虽然外表相同,但是考虑问题的角度却不同。例如在同一个层中,就没有DTO之说了。
但是这些区别并不重要,我的问题是DTO在不同层的属性是不同的,尤其是在以Hibernate为核心的DAO层,VO和PO是不能作为DTO使用的(?)。而表现层的Form数据和业务层所需要的数据也不同。对于一个UseCase而言,是否需要为每一个层都建立一个数据对象呢?

2005-11-11 10:46

〉DTO在不同层的属性是不同的

DTO应该主要是指相邻层的层间传递的,因此只要把相邻的两层间的问题设计好了就行,至于,不同层的属性不同,那不应该属于DTO的问题。

8Go 1 2 3 4 ... 8 下一页

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系管理员 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com