Re: [站內] 找工作真的很難
※ 引述《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
討論串 (同標題文章)