|
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2008-12-22
菜鸟 你哪个学校的？
caipanjin 写道 最近做毕业设计的时候，在持久层的框架用了iBATIS，而没有用Hibernate，但是写了几个模块之后越来越不爽。在做像高级查询的这种需要连接多张表的操作的时候，由于iBATIS并不是真正意义上的ORM，所以不得不为每一种查询的输入参数和输出参数量身定做各种不伦不类的JavaBean，真不知道把他们搁置在哪个包里面，新建一个bizModel包与持久层的model包并列？而写死了的model层跟数据库表对应的对象看起来很鸡肋，因为事实上，就查询而言，进行单表操作很少。大家是什么看法？
看了回帖后的补充，拜托某些只知道骂人的前辈看明白我的意思再回帖： 可能很多人都没理解我的意思，我就问一句好了，在取数据的时候，是该采用增加DTO映射结果呢，还是用Entity？采用DTO的好处是，查询数据对应于一个类的属性，映射简单，取数据也简单，但是会导致类的数量的膨胀。用Entity的好处和坏处正好相反。类的数量不会随着业务的变化而增多，但是映射会变的复杂，取数据需要对应于多个bean，性能也会打折扣。 |
| 返回顶楼 | |
|
发表时间：2008-12-23
LZ,不断的武装自己吧....绝对不能盲目骄傲.
多看看资料,好好研究下hibernate与ibatis. 你缺少实战经验..多作几个项目就好了. |
| 返回顶楼 | |
|
发表时间：2008-12-23
最后修改：2008-12-23
caipanjin 写道 rtm 写道 并不是因为你用了ibatis之后才出现这些你所谓的不伦不类的JavaBean,这些本来应该是你的Domain,而只是用ibatis来持久化,只能说明你主次不分,完全没有概念
Hibernate是完全面向对象来维护关系的，而iBATIS却不是。对于需要多表的操作，持久化怎么一样了？ 实际项目中，如果Hibernate完全面向对象来维护关系就等死吧。 啊，你说Hibernate不是OO么？我告诉你，初学者这么用，一定会有性能问题，而精通Hibernate的人，用到后面就是会把Hibernate当iBatis或者JDBC那样维护，时时刻刻都要考虑生成的sql是长啥样的，说穿了只是把Hibernate当作一个极其高效的Sql生成器而已。 |
| 返回顶楼 | |
|
发表时间：2008-12-23
caipanjin 写道 最近做毕业设计的时候，在持久层的框架用了iBATIS，而没有用Hibernate，但是写了几个模块之后越来越不爽。在做像高级查询的这种需要连接多张表的操作的时候，由于iBATIS并不是真正意义上的ORM，所以不得不为每一种查询的输入参数和输出参数量身定做各种不伦不类的JavaBean，真不知道把他们搁置在哪个包里面，新建一个bizModel包与持久层的model包并列？而写死了的model层跟数据库表对应的对象看起来很鸡肋，因为事实上，就查询而言，进行单表操作很少。大家是什么看法？
看了回帖后的补充，拜托某些只知道骂人的前辈看明白我的意思再回帖： 可能很多人都没理解我的意思，我就问一句好了，在取数据的时候，是该采用增加DTO映射结果呢，还是用Entity？采用DTO的好处是，查询数据对应于一个类的属性，映射简单，取数据也简单，但是会导致类的数量的膨胀。用Entity的好处和坏处正好相反。类的数量不会随着业务的变化而增多，但是映射会变的复杂，取数据需要对应于多个bean，性能也会打折扣。 业务分析上首先要把查询分为两种讨论，一种是普通CRUD中的R，一种是复杂查询（也可以理解为表报查询）。 不管是什么ORM技术，对于第一种都有通用方法，这时候往往用Entity比较合适。 而后者复杂查询，往往用DTO更好。 一开始就幻想有种方案能完美解决这两种情况就是不合适的，要注意二、八原则，只能说大多数项目，第一种查询占了80%的场景。 |
| 返回顶楼 | |
|
发表时间：2008-12-23
fight_bird 写道 caipanjin 写道 ...
1.使用ResultMap的select会产生“N+1”的问题，这是我不想像ORM那么处理的原因。 ... 实际项目中很少出现N+1的问题，而是x/N+1的问题，其中x可以理解为每页的记录数，无需担心。 实际项目，如果是延迟加载多张表的话，就是M×(x/N)+1问题，怎么能无需担心呢？表的关系稍微一复杂，再加上页面上的显示元素牵涉的表比较多的话，很容易出性能问题。 |
| 返回顶楼 | |
|
发表时间：2008-12-23
最后修改：2008-12-23
icewubin 写道 caipanjin 写道 最近做毕业设计的时候，在持久层的框架用了iBATIS，而没有用Hibernate，但是写了几个模块之后越来越不爽。在做像高级查询的这种需要连接多张表的操作的时候，由于iBATIS并不是真正意义上的ORM，所以不得不为每一种查询的输入参数和输出参数量身定做各种不伦不类的JavaBean，真不知道把他们搁置在哪个包里面，新建一个bizModel包与持久层的model包并列？而写死了的model层跟数据库表对应的对象看起来很鸡肋，因为事实上，就查询而言，进行单表操作很少。大家是什么看法？
看了回帖后的补充，拜托某些只知道骂人的前辈看明白我的意思再回帖： 可能很多人都没理解我的意思，我就问一句好了，在取数据的时候，是该采用增加DTO映射结果呢，还是用Entity？采用DTO的好处是，查询数据对应于一个类的属性，映射简单，取数据也简单，但是会导致类的数量的膨胀。用Entity的好处和坏处正好相反。类的数量不会随着业务的变化而增多，但是映射会变的复杂，取数据需要对应于多个bean，性能也会打折扣。 业务分析上首先要把查询分为两种讨论，一种是普通CRUD中的R，一种是复杂查询（也可以理解为表报查询）。 不管是什么ORM技术，对于第一种都有通用方法，这时候往往用Entity比较合适。 而后者复杂查询，往往用DTO更好。 一开始就幻想有种方案能完美解决这两种情况就是不合适的，要注意二、八原则，只能说大多数项目，第一种查询占了80%的场景。 对于报表这种没有逻辑的强大存在,用vo直接去后台,也是种办法. 引用 实际项目，如果是延迟加载多张表的话，就是M×(x/N)+1问题，怎么能无需担心呢？表的关系稍微一复杂，再加上页面上的显示元素牵涉的表比较多的话，很容易出性能问题。 这时先应该去调优缓存..... 再考虑sql的数量问题 icewubin 写道 jltest 写道 复杂的查询直接写sql语句。速度快效率高。
hibernate ibatis不是用来干这个的。。。 绝对可以的，hibernate的hql在写中等的复杂查询的时候，绝对比直接写sql要简单很多。 Hibernate有很多用法，做复杂查询时，完全可以不理会什么OO概念的，返回的还可以直接映射成DTO。 对的.还可以用hibernate的native来作,还可以使用oracle特有的变态函数 |
| 返回顶楼 | |
|
发表时间：2008-12-23
jltest 写道 复杂的查询直接写sql语句。速度快效率高。
hibernate ibatis不是用来干这个的。。。 绝对可以的，hibernate的hql在写中等的复杂查询的时候，绝对比直接写sql要简单很多。 Hibernate有很多用法，做复杂查询时，完全可以不理会什么OO概念的，返回的还可以直接映射成DTO。 |
| 返回顶楼 | |
|
发表时间：2008-12-23
rainsilence 写道 lz我送你句话，包你一生受用
你去死吧 ibatis和hibernate哪个更快？ orm程度越高，速度越慢，什么都不懂就不要乱说 你搞笑，偏偏Hibernate是个矛盾结合体，只要你用的好，性能还能提升。 另外什么叫“orm程度越高”？照你的逻辑，我可以告诉你Hibernate本身支持多级别的“orm程度”，从JDBC到完全的OO，hibernate都支持。 |
| 返回顶楼 | |
|
发表时间：2008-12-23
最后修改：2008-12-23
抛出异常的爱 写道 引用 实际项目，如果是延迟加载多张表的话，就是M×(x/N)+1问题，怎么能无需担心呢？表的关系稍微一复杂，再加上页面上的显示元素牵涉的表比较多的话，很容易出性能问题。 这时先应该去调优缓存..... 啊，看到一位懂Hibernate的言论了。 我的观点，某个页面牵涉到M×(x/N)+1问题，与其利用Hibernate调优缓存，不如自己设计业务缓存。 1.M×(x/N)+1问题，通过调优Hibernate一级缓存和二级缓存，仅仅是缓解性能问题而已，而且这种调优往往还带有点通用性质，就是期望这个调优后的缓存能够被其他页面利用到，如果真能利用到，那这个缓存还是有价值的。 先说1级缓存，如果这个查询中用到了这些对象，那1级缓存是能命中不少延迟加载的findById产生的sql语句的，但是大多数查询不是这样的，所以要调优基本就是靠二级缓存了，我一直反对用二级缓存，内存空间类用效率低不说，还阻碍SNA的架构设计。Hibernate二级缓存设计和配置的复杂度都快超过自己设计一个的工作量了。 有这点时间配置调优Hibernate二级缓存，还不如利用项目中已有的数据字典缓存结构（解决80%的问题），再针对各个项目自己业务的特点，直接配置业务对象缓存（绝对比直接利用Hibernate二级缓存要省内存占用）。 2.M×(x/N)+1问题，很难说直接用sql和用对象缓存到底哪个好，我感觉实际项目中，大多数情况下，花个10分钟，写个有针对性的hql，自动映射到DTO上，在Hibernate中是很简单的事，而且维护简单，需求变化，改个hql就可以了（不知道其他公司是怎样的，我们因为利用数据字典的缓存的原因，写hql的时候往往能少关联很多表）。不然，需求变更还要评估之前调优的缓存是否能适用，如果维护代码的人不是当初写代码的人，这个维护难度很高的。 |
| 返回顶楼 | |
|
发表时间：2008-12-23
不得不为每一种查询的输入参数和输出参数量身定做各种不伦不类的JavaBean???
楼主不会传Map吗?定制不伦不类的JAVABEAN,呵呵,没弄懂就不要知己说. |
| 返回顶楼 | |
