Re: [站內] 找工作真的很難
※ 引述《Lordaeron (Terry)》之銘言：
: ※ 引述《tsumarahi (kapa)》之銘言：
: : 哈哈,我可沒說hibernate萬歲,第一名,哪隻眼睛看我說hibernate非常好?
: : 我只是要說你舉的例子超爛XD...
: : 求救,不好意思,我常在www.javaworld.com.tw發言,所以比較少上ptt java板
: : 這次會PO文就是怕你誤導人
: : 如果別人真的相信你寫的,還真的以為不能partial select呢...
: : 好處唷,我這次PO文只是單純想回你爛例子,所以我應該沒有義務要回
: : 哇哈哈,我想你也沒興趣:p
: : 我很喜歡看不好的例子,我也支持hibernate不是最好,
: : 我回文再提一次,我只是...想說你那例子不適當,謝謝惠顧
: 適不適當, 隨你怎麼看, 你也大可以說, 用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做得到.
--
※ 編輯: tsumarahi 來自: 140.138.150.67 (06/15 01:35)
討論串 (同標題文章)