|
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-12-21
不能动点脑子，怪ibatis
|
| 返回顶楼 | |
|
发表时间：2008-12-21
最后修改：2008-12-21
120个属性的pojo对应一个表
重构之 型成一个子目录 子目录里面30多个bean 主bean里10多个属性 但所有的查询还是用原来的bean名 |
| 返回顶楼 | |
|
发表时间：2008-12-21
最后修改：2008-12-21
抛出异常的爱 写道 120个属性的pojo对应一个表
重构之 型成一个子目录 子目录里面30多个bean 主bean里10多个属性 但所有的查询还是用原来的bean名 把大bean拆成30多个小bean了？ “子目录”？以及“所有的查询还是用原来的bean名”？能再解释清楚一点么？ 按照目前的理解，我以为30多个小bean组装起来操作也不比直接操作120个属性的大bean简单多少。 |
| 返回顶楼 | |
|
发表时间：2008-12-21
最后修改：2008-12-21
pf_miles 写道 过多地定义DTO的情况是可以被避免的：
对于查询参数那块儿，你的parameterClass可以指定为'map'，且为了隐藏这一事实，你可以在dao或者repository的具体实现中去构建这个map，而对上层暴露的dao或repository接口只列出具有业务意义的具体查询参数； 对于返回结果那块儿，resultClass完全可以指定成你的domainModel，而不必另外定义DTO，且ibatis也支持自动组装对象树以及延迟加载，具体可查阅文档。 如果用resultClass，那么实体类岂不是要像Hibernate那样去维护对象之间的关系？SQLmap的优势就没了，而且让数据存取变得更复杂化了，性能也会大打折扣吧 |
| 返回顶楼 | |
|
发表时间：2008-12-21
你已经下了定论了， 已经表明你对ORM的认识也就是那么点了。 首先， IBATIS从头到尾都没有说自己是个ORM工具， 他应该是个SQL MAPPING工具。 另外， JAVABEAN的作用你也不是你想象的那点作用。 奉劝你多学学设计模式， 多学学程序设计本身之外的东西。 别动不动就说不伦不类， 好像全世界的程序员都是傻的一样。
－－－好久没有说这么愤青话了， 楼主笑纳不？ |
| 返回顶楼 | |
|
发表时间：2008-12-21
caipanjin 写道 pf_miles 写道 过多地定义DTO的情况是可以被避免的：
对于查询参数那块儿，你的parameterClass可以指定为'map'，且为了隐藏这一事实，你可以在dao或者repository的具体实现中去构建这个map，而对上层暴露的dao或repository接口只列出具有业务意义的具体查询参数； 对于返回结果那块儿，resultClass完全可以指定成你的domainModel，而不必另外定义DTO，且ibatis也支持自动组装对象树以及延迟加载，具体可查阅文档。 如果用resultClass，那么实体类岂不是要像Hibernate那样去维护对象之间的关系？SQLmap的优势就没了，而且让数据存取变得更复杂化了，性能也会大打折扣吧 笔误，是resultMap，可以在这个map里面定义你想要的关系； ibatis给予的自由就是什么时候要取出什么东西必须要你自己定义，所以你必须要考虑好是否在取出一份数据的时候同时也取出它的关系数据，这个一般是按业务层逻辑的需要来定的； 至于性能，如果你的设计没有重大错误，那么应该是最后再考虑或者说需要的时候再考虑的东西。 |
| 返回顶楼 | |
|
发表时间：2008-12-21
楼主在虾机扒扯.
|
| 返回顶楼 | |
|
发表时间：2008-12-21
sdh5724 写道 你已经下了定论了， 已经表明你对ORM的认识也就是那么点了。 首先， IBATIS从头到尾都没有说自己是个ORM工具， 他应该是个SQL MAPPING工具。 另外， JAVABEAN的作用你也不是你想象的那点作用。 奉劝你多学学设计模式， 多学学程序设计本身之外的东西。 别动不动就说不伦不类， 好像全世界的程序员都是傻的一样。
－－－好久没有说这么愤青话了， 楼主笑纳不？ 从您的口气看，想必对手设计模式等方面很有研究，那么怎么就吐不出一句有点建设性的话呢。我没有说iBATIS是ORM的，相反我正是在对比ORM和SQLmap之间设计的选择。至于您说的JAVABEAN的作用，您倒是说说该怎么作用啊，我就是想知道，怎么去用JavaBean能够减少复杂业务带来的数量的膨胀，同时让设计更合理一点。 |
| 返回顶楼 | |
|
发表时间：2008-12-21
可能很多人都没理解我的意思，我就问一句好了，在取数据的时候，是该采用DTO呢，还是用Entity？采用DTO的好处是，查询数据对应于一个类的属性，映射简单，取数据也简单，但是会导致类的数量的膨胀。用Entity的好处和坏处正好相反。类的数量不会随着业务的变化而增多，但是映射会变的复杂，取数据需要跨越多个bean，性能也会打折扣。
|
| 返回顶楼 | |
|
发表时间：2008-12-21
小的不才，爷您发个贴， 小的就要跟您说怎么用设计模式， 怎么用JAVABEAN的理论。很多人用了很多年的时间明白这些， 您该不会发个贴就想个明白， 不是么？
|
| 返回顶楼 | |
