※ 引述《Lordaeron (Terry)》之铭言： : 不好意思, 我有提出问题, 你们都回答了. : 但你们有提出它的benefit 吗? : 我也提出质疑, 你既然要会SQL, HQL, hibernate 整个架构 : 整整多了一倍的功夫, 请问它为你带来的效益是什麽? OR Mapping 顾名思义是帮你做 Object and Relational (DB) 的 data mapping. 要是你的系统有对 persistence layer 和 business layer 作 decoupling 你该会明白 这在 solve 的是什麽. : 所以是为观念而做的调整, 而不是视实际状而做的? : 我是一位不信oo model, xx model的能为你带来xx, yy 的人 我不明白你所谓为观念而做而非为实际状况而做是什麽意思. persistence layer 和 business layer decoupling 这 种极基本的 design philosophy 有什麽 "不视实际状况"呢? : 我是没试过什麽大同小异的sql 会在不同的程式中出现. : 希望你的大同小异和我的大同小异是类似的定义吧. 要是你没有define domain model, 没有企图去作 persistence-business layer 的 decoupling, 作的都是 DB-oriented 的设计, 或者你不会有这种 问题. 否则的话, 你不会不了解写一堆 JDBC DAO, 每个都要做 enquiry 然後再把 resultset 放回一个个 domain object 这种重覆的工序, 请问, 它 automate 你的 relational result <-> object model 的 mapping, 是不是有它的价 值? : : 东西塞进 domain model, 或者要兼顾 concurrent : : update 时的问题 ( => 处身在问题中). 这 : : 时你才能体会 Hibernate 等的 OR Mapping : : framework 究竟在解决你什麽问题、它的价 : : 值是什麽. : 完全没有想过什麽concurrent update 的问题. : 只要同时抓到同一笔资料, 要同时做更新. : 本来就是有後盖前的情形, 如果是帐务类, 扣, 冲, 入帐的问题. : 就比较奇怪了, 这个东西, 丢到一个queue 中让它顺序去做不就好了? : 再不然, 就是row lock 而已, 不过有db 不support row lock就是了. transaciton based 当然可以这样做. 但如果是大家retrieve 同一个 record, 你改了 field A 我改了 field B, 你不理会 concurrent update 的话 你改的东西就消失了. 当然你可以自己在 table 再加 sequence number 再在 update 前检查一下有没有人在之前 update 过, 但这种 optimistic concurrency strategy, 不少 OR Mapping framework 已经帮你做了一大部份了, 请问, 这是不是有它的价值? : : 无疑没有一个 framework 能解决所有问题, : : 所以才要选择 framework, 因应自己要解决的问 : : 题来选适当的解决方法, 而不是一直企图证 : : 明某framework 不是一把万用刀而否定其存在价 : : 值. : : Alien --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 202.22.246.26