值对象与DTO

值对象VALUE OBJECT VS. DATA TRANSFER OBJECT (VO VS. DTO)

J2EE Core J2EE Patterns J2EE核心模式中对DTO和VO定义使人容易误解，一篇博客专门写了一篇两者对比文章，正是我本人想说的：
1. DTO只是愚蠢的数据容器，用于在层之间进行数据传送。它主要包含的属性。实际上，您甚至可以直接使用公共属性，无需任何set/get方法，但是这可能会造成太多的会议和讨论:-) 。 DTOs是贫血，一般不包含任何业务逻辑。 DTOs往往java.io.Serializable -其唯一的需要，就是如果你需要在跨JVM之间传输数据。

2.值对象代表本身就是一个固定的一组数据和类似于Java的枚举。值对象没有任何身份，是不可改变的。一个真实的世界将是Color.RED例如， Color.BLUE ， SEX.FEMALE等(注：这与Evans DDD中定义值对象是一致的)

值对象和DTO被大量过度使用，属于无人看管方式，造成系统的复杂性，大多数使用值对象概念其实心里是在使用DTO。这个现象必须克服。

banq注：唯一克服的办法就是使用DDD领域建模，确定模型群，划分边界，让值对象附属于实体根。

http://www.adam-bien.com/roller/abien/entry/value_object_vs_data_transfer

大概出于不同的目的，表现出一样形态的东西。

还有一种克服的办法，就是纯SQL编程，没有DDD，没有OO，一切都是SQL，写最烂的代码，用最烂的架构，吧ResultSet往页面上传（!）。这种办法的好处是不会引发任何会议和讨论:)
PS:我不是来捣乱的，只是希望这个地方更像一个论坛——说啥的都有。

>>一切都是SQL，写最烂的代码，用最烂的架构，吧ResultSet往页面上传（!）
我就在干这样的事情，发现java编程不过如此！呵呵
晚上下班了就打开笔记本瞻仰一下里面的DDD sample

还有一种克服的办法，就是纯SQL编程，没有DDD，没有OO，一切都是SQL，写最烂的代码，用最烂的架构，吧ResultSet往页面上传（!）。这种办法有啥不好啊，搞个设计多麻烦，软件反正能用就行了，其他的不用管。管它啥DOMAIN,DTO,DAO，全部不需要。
PS:我不是来捣乱的，只是希望这个地方更像一个论坛——说啥的都有。

DTO是不是不仅限于JVM对JVM的远程传输，也用于同一个JVM中层与层的传输？在同一个JVM中，DTO和VO经常是被混用的，VO包含的数据是高度亲密有共同业务含义的数据，DTO只作为数据的载体。例如一个页面上之需要有图书馆的简介和图书馆中书本的价格，那么用DTO向表现层传输图书馆简介和书本价格的封装体，而在VO中这两者不可能封装在一起，因为没有共同的业务含义。

>一个页面上之需要有图书馆的简介和图书馆中书本的价格

如果是这个需求：按照DDD设计，图书馆是一个实体，存在一个值对象：简介，书本应该是一个根实体，价格是其一个值对象。

如果界面需要有图书馆的简介和图书馆中书本的价格，那么我首先从DDD实体之间聚合关系看能够满足这个要求，比如向页面推出书本这个根实体，在以书本为根的这个边界中，是否有图书馆这个实体，价格肯定有的，如果有图书馆这个实体，那么简介也能通过遍历找到。

首先使用根实体为核心的进行边界内遍历访问，如果能满足页面需要，是最好，否则使用DDD中的无根值对象进行临时组合满足需要，这时值对象可以认为是临时对象。

所以，在DDD概念中，已经没有DTO，只有SOA概念中才有DTO，而DDD和SOA两个架构侧重点不一样。

这是一个术语标准化进化的问题
1. Value Object最早被Java用来表示DTO. http://en.wikipedia.org/wiki/Value_object
2. Martin Fowler则分别用来表示两个不同的概念.所以才造成概念紊乱.
http://martinfowler.com/eaaCatalog/dataTransferObject.html
http://martinfowler.com/eaaCatalog/valueObject.html

如果要清晰的讨论,应该用Martin的定义为标准.