j2ee绿洲

DTO的转换规律一般可以总结为如下的几个类型，实际变化则可以是各种类型的组合：

• 属性内容的减少

属 性内容的增减在DTO不同形态之间的转变时候经常会发生。比如上例中添加用户LoginInfo对象的VO转换到BO的时候，就需要丢弃“重复输入密码” 的属性。有些VO对象甚至根本不需要转换成BO。在BO转换成PO的时候同样也会有属性内容减少的情况出现，比如“部门”这类树状层次结构对象，因为运行 效率的因素，也许会需要BO中有“下级部门列表”，实际存储到数据库的时候，PO只需要一个“上级部门ID”就可以了。

• 对象内容的填充或者增加

属 性内容同样会有可能增加，但是在系统处理DTO转换的时候，属性增加可能就意味着需要进行额外的查询和填充，比如我们使用“用户名”和“密码”进行登录的 时候，最终系统需要通过数据库查询得到并且存储“用户ID”，以此来保证用户的唯一性。又比如提交的数据存在校验错误，我们可能需要重新刷新该页面，并且 增加新属性“ErrorMessage”，以便把它显示在界面上，提醒用户注意。

• 对象的拆分和组合

我们可以看上面最后一个“添加用户”的例子，一个LoginInfo的BO转化为PO的时候被拆分成了2个对象，一个存放基本的用户信息，一个存放对应的Role信息。通常对象拆分的时候，常常需要填充或者补足新对象的内容；而对象合并的时候，常常出现内容减少的情况。

• 对象或者属性类型的变化

出现对象属性类型的变化在VO到BO的转换中比较常见，比如把用户输入的生日转化为一个真正的DateTime类型。

• 属性名称的变化

属性名称在转换过程中会有变化，一般这种情况应该尽可能不要出现，但是在项目重构的时候出现的概率较大。

除了DTO不同形态之间的转换规律之外，不同形态内部还有不同的工作要做：

• 校验

“ 不要相信任何用户的输入”，这是设计程序跟用户进行交互操作时候永远需要遵守的一个原则。也就是所有的外部输入都需要进行正确性的校验。校验器是分为两个 层次，一个是属性层次的校验，比如“年龄”只能0到150之间有效。另外一个是对象层次的校验，或者说跨属性层次的校验，比如“年份输入闰年的时候，2月 可以有29日”等。

校验并不是一个单纯的问题，几乎所有的业务逻辑校验基本都需要一次完整的贯穿所有层次的调用。代价颇大。这个也是为什么我们在显示层做很多事先校验，而一旦进入业务逻辑层的时候，校验就经常会被“事后校验”代替了，人们会使用抛出异常的方法来代替“事前检查”。