※ 引述《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