幸福是一种心情、一种体会

认真学习,虚心向高手们请教

导航

统计

公告

请教Entity/VO/DTO/Domain Object/Biz Object等名词的含义

一、VO和DTO
VO:  Value Object
DTO: Data Transfer Object
个人理解VO和DTO是类似的东西,原则上VO和DTO只有Public Fields,主要用于进程之间数据传递的问题,VO和DTO不会传递到表示层,在业务层就会被吸收。但看到很多人在建立VO和DTO时,也
含有Setter,Getter属性和一些其它的辅助方法,这也无可厚非,我自己也不能确定这对不对。望大家给出意见。

二、Entity和Domain Object
Entity和Domain Object应该是类似的东西,我觉得这两者概念上可能与Biz Object(Business Object)有所不同,但我看到网上很多文档都把
他们当成类似的东西。
Entity和Domain Object除了有Setter,Getter属性外,还有仅仅属于自己的一些专有(special)方法,如CRUD及其他专有方法,和有一些
Services接口,并不涉及Domain Object与Domain Object之间关系的一些方法。也就是说Domain Object负责数据持久化,这可以由其IDataServices接口来实现。Entity和Domain Object更强调具体是哪一个对象,或者说是实例化的Entity和Domain Object对象。
如果用Domain Object来设计程序,不自觉地就会遵守一些重构策略(如Divergent Change、Shotgun Surgery、Switch Statements等,具体可
以看Rickie的blog),我们知道Domain Driven Design这本书出现在Refactoring这本书之后,看来也是Martin Fowler对Refactoring进一步总结、升华的结果。用Domain Object来设计程序,降低了类之间的耦合,可以不自觉地达到Refactoring结果。看来出现Refactoring后,Domain Object的出现只是时间的问题。

idior的O/R Mapping 基本概念一个困扰我长时间的问题也谈到了Entity和Domain Object

三、Biz Object
个人理解Biz Object更加专注于业务实现,主要强调业务类之间的关系。这也是它与Entity或Domain Object的不同之处。
在具体的程序中有时还会有Manager类,用于管理Biz Object和作为Biz Object的Facade。

我一直没有成型的架构,下一步抽时间看看Domain Model 探索EDRA,我更觉得架构不用通用,可以根据一些典型的业务建立合适的架构,更希望大家能给出好的架构。

posted on 2005-09-03 21:59 生活、工作 阅读(...) 评论(...) 编辑 收藏