有必要TO和对象进行分离吗？为什么要分离？
分离实现了数据与功能的分离在传递数据时没有必要传递功能接口仅仅是数据的传递为什么要把功能接口暴露给web层？web层见到的只有数据避免了的web层程序员的调用接口沖动而实际上在web层调用是错误的
这个理解有问题功能接口的控制可以通过访问控制关键字来控制比如只有包权限
但是TO和对象分离以后有重复的数据那为什么不避免重复？
思路是TO只携带必须的数据抛弃一切多余的数据提高传输性能
有必要吗？就那么一点点性能
好像没有必要但是web层在构造数据的时候他不可能传递也没有必要传递id之外的任何数据
这很容易解决阿让id之外的数据空着好了
为什么不让业务对象继承TO？
防止业务对象和TO耦合太紧
但是TO作为成员变量实际上也是一种紧耦合？
相对来讲继承的耦合性比成员变量的耦合性要强一些比如我完全可以换掉成员变量使用别的方式来保存数据
不对吧你构造函数本来就使用了TO这是一种强耦合
但是成员变量方式要写大量的重复代码比如我要改变一个属性的值你就要提供set方法他只是进行了传递这是一种重复
这个问题我可以提供getTO方法让人调用然后让客户使用TO的set方法
呵呵这样岂不是又让耦合性增强了？我使用继承的方式可以让业务对象很容易的用于spring架构中
TO中的引用TO为什么要数组？
这样就不用类型转换了阿
但是你在增加删除等操作数据的时候岂不是很麻烦？使用数组只是在读取的时候比较方便而增加删除的操作要频繁得多读取的麻烦可以通过转换为数组来简化List等转换为数据并不难而且业务对象可以直接使用这些List作为容器不用再引入其他List做容器避免了代码重复
简单的增删改查有必要用面向对象那么复杂吗？不就是把信息更新到数据库吗？
粒度细化以后使用面向对象的东西能够带来重用啊今后不用老改
