※ 引述《kithe (城市天際線)》之銘言： : ※ 引述《Lordaeron (Terry)》之銘言： : : 我比較好奇的是, 最後有解嗎? : : framework 已經很明顯顯的跟user 講了, 在我的frame 中work. : : but 台灣人還是愛盲從, 而不是理性對待. 總希望有一個救世主 : : 可以打遍天下無敵手, 讓自己無往而不利. : : 而讓自己忘記基礎的重要. : 你所謂的framework難道只是針對hibernate? : 通常每種framework都是針對特定條件或特定問題而設計的吧 : 如果你覺得hibernate很爛,那就不要用阿 : 自己搞一套ORMapping(or DBUtil, DBHelper)也行阿 : 只要你搞出來的東西,經得起實戰的考驗 : 你在公司的地位夠有份量 : 可以說服大家follow你設計的腳步 : 你愛怎麼搞就怎麼搞 : 沒有人說會使用framework就可以說話大聲,忽略基本功吧? : 真正能夠巧妙運用各種framework的強者,基本功夫會差嗎? : 光是framework的整合,效能調教就是一門學問吧 : 使用framework跟駕馭framework本來就是兩回事 : 什麼framework都不用,什麼thirdparty library都不import : 就是你所謂的基本功嗎? : 套句老師說的話 : 選對framework可以讓你上天堂 : 選錯則.... : hibernate說實在的,我只會用一些基本的功能 : 撇開效能的問題不談, : 當資料庫schema變動頻率跟幅度很大的時候 : 透過hibernate + middlegen,可以很快的重建所有POJO : 快速修正所有被影響的程式,加上適當的UnitTest : 這樣應該可以比較保證程式的品質吧 : 不然照小弟之前寫native SQL的方式 : 資料庫只要一改欄位,一定會提心吊膽好一陣子 : 深怕有什麼地方沒寫好,沒改到,一旦跑到就跳出那種很難看的Exception.. : 從這個角度來看,我覺得hibernate還蠻好用的 : 只要你能搞一套類似的東西,可以保證schema變動的時候 : 程式依然可以維持一定的品質 : 不用hibernate當然是無所謂的 : 我也看過有人搞過類似的東西 : 不過說實在的,maintain這種高手寫出來的東西,實在一點也不輕鬆 : hibernate好歹網路上有一堆的文件可以查 : 高手寫的東西搞不好還會暗慷一些自己的小玩意兒 : 變成你必須先了解前人的想法,才有辦法維護他的程式 : 這樣對公司來說是好是壞,見仁見智吧 : 熱門的framework,某種程度來說算是業界的隱藏標準吧 : 摸過學過碰過一些問題,好歹可以比較一下優缺點 : 不用這些framework or thirdparty的元件,靠自己就會學到真功夫? 如果你是為hibernate 選舉的人, 哪麼請你將它的 優缺點, 局限制全都指出來吧. 不然, 你的<儮髽ramework可以讓你上天堂> 就是一句空話而已, 寫SQL 會碰到加減field 的問題, 寫hibernate 就不會? 哪是你用JDBC 的問題. 所以你洋洋灑灑的為hibernate 辯護, 希望是實是求是, 不是選舉支持. 請你給出實例和優缺點, 局限等吧. --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.229.144.200