领域相关的模型里面需要3种对象

基本上一个应用程序里面的领域相关的模型里面需要3种对象：
1。值对象(Value Object)，没有身份，内容表示一切，譬如我和weihello都去银行里面存取100大洋，那这个100RMB是一个值对象

2。实体对象（Entity)，需要持久，不是按照内容，而是按照它的身份来区分，也就是说即使内容完全一样，也不是同一个对象。这个身份在内存里面是它的实例地址，在数据库里面是关键字，最常见的就是OID.这个实体对象并不是纯数据，它处理本身的实体模型，例如Accout，它的 withDraw,它的子Account等等，它也处理自己和其他实体对象之间的关系，例如订单里面的订单行，都是应该在这个Account里面实现的，而不应该有一个什么控制类。在一个Web应用程序里面，涉及到对象关系的一般只需要一个（或几个）DTOFactory负责所有对象的DTO和 Entity之间的组装和拆份，不需要专门的管理，这一部分也是和数据建模最相近的地方。

3。服务对象(Service)，这是为我们提供服务的类，譬如银行里面服务员，她帮助我们把钱从一个账户转到另外一个账户，并记录相应的交易。

对象的作用是对它自己的内部状态负责，如果它需要存取很多其它对象的状态进行运算，那叫做特性忌妒，是要重构的。应该把这些代码移到那个持有这些状态的类里面


辨别一些名词：
1。VO：实际上很模糊，通常指ValueObject和ViewObject
2. ViewObject，界面展现需要的对象，如Struts的FormBean
3。Value Object，早期被作为ValueObject和Transfer Object的总称。实际上Value Object的真正意义在于它的内容，而不是身份
4。Transfer Object：数据传输对象，在应用程序不同层次之间传书对象，在一个分布式应用程序中，通常可以提高整体的性能
5。PO：也许就是Persistent Object，基本上就是Entity了
在不同的体系结构和实现方式里面，这些对象有可能重复，也有可能不重叠。如果你要做一个对所有的体系都能够方便移植的框架，那么每一种对象都需要严格区分。例如JDO的PO不能作为TO，应为它不能脱离PM，譬如你可以选择用ViewObject（如Struts的FOrmBean)直接作为 TO，但在tapestry和Webwork里面就不合适了。但在很多时候，能够方便实用是最重要的，不要过度设计就是了。