※ 引述《tsumarahi (kapa)》之铭言： : ※ 引述《Lordaeron (Terry)》之铭言： : : 适不适当, 随你怎麽看, 你也大可以说, 用hibernate 我最最大不了就是 : : 用native SQL, 也没什麽辨不到的. 如果是这样, 请问你花时间去hibernate : : 做什麽? : : 要吵hibernate 的好坏, 刚好找到一堆人在吵的地方. : : http://robbin.javaeye.com/blog/24360?page=1#comments : : 其它有人提出一个比我好的scheme: : : ----------------------------------------------------- : : 例如有个业务场景，Department和Employee是一对多关系。现在我 : : 对Department进行分页查询，要求在显示的页面上同时显示每 : : 个Department中Employee的数量。这是一个很简单的业务场景， : : 但是想像一下如何用hibernate进行映射？ : : 首先否定一种做法：hql：FROM Department department。然後针对每 : : 个department，去做department.getEmployees().size()。 : : 这样不仅会发送n＋1条SQL，而且性能太低。 : : 我们肯定希望采用一句HQL解决问题，但是此时问题来了，当你 : : 试图做SELECT department, count(employee.id) FROM ..... : : 这样的HQL时，在Java端，发现没有一个合适的对象可以映射。 : : ----------------------------------------------------------- : 唉..看文章要看完,後面都有人提怎麽解了 : 只是解能不能接受的程度罢了 : 一种使用constructor,新增一个constructor,然後回传就可以. : 别像里面的人提到什麽不能重复利用,什麽东西做出来都考虑重复利用, : 那别写程式了.可以利用的当然重复利用,但是有些东西为了效能跟方便考量 : 得另外特化那就得特化. : 另外前端有没有合适的mapping, 这..坚持一定要mapping成物件? : 脑筋太死了.乾脆说为什麽没有东西代表select count(*)好了. : 用了OR mapping难道捞出来的资料一定得是OO? : 因为用JDBC所以不用OO没关系?这什麽鸟逻辑? : framework只是个一个更大的pattern,也是tool,不是个枷锁. : (当然如果功能不够时确实是枷锁哈哈哈) : 说真的,人都爱看自己想看的,看完全部讨论吧 : 真那麽烂robbin还会说目前最好的就是Hibernate了吗, : robbin现在可是嫌它嫌很大(他的心已经被ROR拿走了..哭哭). : 会说如果利用Java开发他会选hibernate/spring/ww吗? : 另外这是2006的,2007我记得也还有不错讨论可以看,可以去javaeye看看 : robbin在今年的gavin去中国时也另外做了优化投影片 : 看看人家认真研究懂得评估,也举的出好例子 : 我并没有否定hibernate的不完美,很多framework都不完美 : 我也支持不理解乾脆不要用,不然只是制造麻烦 : 我只是回你,你的例子很烂,不需要跟我说hibernate哪边不好, : 他有很多可以提的地方...我只是怕你误导人,所以提醒你那句hql : 在hibernate做得到. 我从来没将谁的话当成铭言, 後面有解, 但原发问者也相应的提出 它的疑问. 就像是你说的, 用OO 後, 突出一个不OO 来解决问题. 我还是哪句话, 今天你为了使用hibernate 依然要同时会hibernate 和sql 哪就得要问一句, hibernate 为你带来的效益是什麽了? 我是没比较过用了hibernate 後, 比没用时, 到底带来 效益的差异到底多少, 例如, 开发速度比较快, 快多少? db access 比较少, 但少多少? 系统跑起来比较快, 快多少? 既然你这麽熟hibernate, 相信做过的hibernate 的case 不少, 有以上的数字吗? --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.229.146.186