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