我的空間,寫我所寫,禪我所藏

          與我一起遨游吧

           

          Hibernate影響設計思路

          總覺得Hibernate影響設計思路 發(fā)表: 2006年07月23日 08:09 回復
          玩hibernate有些日子了,但一直沒敢在大型項目里用,主要是有種感覺:hibernate對設計思路有很大的干擾。

          說個具體的例子:
          很多應用都要求記錄某一個業(yè)務對象的變更的歷史,比如說,一個issue-tracking系統(tǒng)里,對issue的每一個處理步驟都要有紀錄。這時,數(shù)據(jù)庫通常設計為一個主表和若干個屬性表,主表中保存業(yè)務對象不會變的屬性,例如ID等等,屬性表中記錄經(jīng)常更新的屬性,兩個表用主表ID相關聯(lián)。若屬性發(fā)生的修改,主表中不會變化,而屬性表中會加入一個新的紀錄,紀錄中保存新的屬性值、創(chuàng)建時間、創(chuàng)建人等等。

          這樣的設計應該是很常用的,但是若使用hibernate來實現(xiàn),總覺得相當別扭。特別感覺OR-Mapping似乎對業(yè)務邏輯設計有很大的影響。比如:
          理想的方法,應該是把整個業(yè)務對象表達成一個類(包括在主表中的屬性和在屬性表中的屬性)。可是使用hibernate,如何做這種mapping?
          如果把一些屬性單獨抽象成類,,這個屬性類的實例作為主類的一個屬性保存。這樣對hibernate實現(xiàn)倒是簡單了,只要一個one-to-many影射就好,但是這樣業(yè)務邏輯表達上就嚴重不爽了。

          不知道有沒有DX處理過這類問題?

          banq

          發(fā)表文章: 7538
          注冊時間: 2002年08月03日 17:08

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年07月24日 17:55 回復
          》hibernate對設計思路有很大的干擾
          非常正確的感受,這就是數(shù)據(jù)庫驅動設計和模型驅動設計不匹配引起的,因為你的習慣思路是數(shù)據(jù)庫驅動設計思路,而Hibernate則是模型驅動設計思路,所以,你覺得有干擾,對抗發(fā)生了。

          >應該是把整個業(yè)務對象表達成一個類(包括在主表中的屬性和在屬性表中的屬性)。可是使用hibernate,如何做這種mapping?
          這就需要使用到DDD領域驅動設計,首先設計出領域模型Model,然后再使用Hibernate等mapping工具將其持久化。

          在你腦海中去除數(shù)據(jù)庫設計影子,才能嫻熟使用Hibernate這些為OO服務的框架,如果你的思維不是OO,當然干擾就會發(fā)生,問題出在你自身啊。

          參考:面向ο蠓治`^程

          strangecat2005

          發(fā)表文章: 8
          注冊時間: 2006年07月23日 07:57

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年07月25日 13:13 回復
          strangecat20056M1NVeQg5v.png

          我覺得不可能徹底的和數(shù)據(jù)庫特型剝離。說一個具體的例子吧。背景看上面的圖,基本上Issue類寫成下面這樣:


          class Issue{
          ...
          List issuePropPackList;

          public IssuePropPack getCurrentIssuePropPack(){
          }

          public IssuePropPack getHistoryIssuePropPack(){
          }


          public List getHistoryPropPackList(){
          }

          }


          那么,getCurrent/History IssuePropPack這兩個方法如何寫?標準OO應該是從List里面找,因為這是它的屬性;但是實際上,估計多數(shù)人會用HQL直接查數(shù)據(jù)庫,找兩個PropPack--為了效率著想。


          strangecat2005

          發(fā)表文章: 8
          注冊時間: 2006年07月23日 07:57

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年07月25日 17:44 回復
          但是,使用HQL來找相應的實例,明顯就是在設計實現(xiàn)中引入了數(shù)據(jù)庫的概念了...

          j10A

          發(fā)表文章: 32
          注冊時間: 2006年03月11日 09:13

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年07月25日 18:43 回復
          若你一定要勉強采用所謂OO,無疑是畫地為牢。過分的強調OO,只會讓你的設計變的呆板。怎么定義先進?倒覺得你應該仔細考慮這個問題。

          strangecat2005

          發(fā)表文章: 8
          注冊時間: 2006年07月23日 07:57

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年07月25日 20:24 回復
          > 若你一定要勉強采用所謂OO,無疑是畫地為牢。過分的強調OO
          > 換崛媚愕納杓票淶拇舭濉T趺炊ㄒ逑冉康咕醯媚閿Ω米邢
          > 考慮這個問題。

          我正式覺得不能強往OO上靠,才會想討論這個問題的。

          把別人的方法論想透,或者理出屬于自己的方法論,把事情想透了,用起來才有章法。



          banq

          發(fā)表文章: 7538
          注冊時間: 2002年08月03日 17:08

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年07月26日 18:44 回復
          >我覺得不可能徹底的和數(shù)據(jù)庫特型剝離。說一個具體的例子吧。背景看上面的圖,基本上Issue類寫成下面這樣

          這是一個一對多的關聯(lián)關系,建立好這個模型后,當我們從Hibernate持久層獲得Issue對象時(需要定義Hibernate的mapping的one-to-many關系),Issue的issuePropPackList集合已經(jīng)有數(shù)據(jù)(可采取Open session in view提高效率)。

          因此,業(yè)務層獲得的Issue是一個完整的與數(shù)據(jù)庫無關的完全OO對象;

          如果不使用Hibernate,則在業(yè)務層和持久層之間封裝一個工廠,專門來生產(chǎn)Issue對象,然后充實Issue的issuePropPackList集合屬性,如果因為效率,可以考慮使用DDD推薦的組合模式(Respository)又被翻譯成倉儲,主要用來返回一批對象,查詢組合常用來返回批量查詢結果。

          數(shù)據(jù)是從數(shù)據(jù)庫獲得,但是數(shù)據(jù)庫的影響完全從業(yè)務層杜絕了,排除了在業(yè)務核心代碼中隨時出現(xiàn)的數(shù)據(jù)庫訪問,這樣的代碼肯定不能重用性;也反映程序員是在寫流水帳,想到什么數(shù)據(jù)就從數(shù)據(jù)庫取,很隨意,這樣的流水帳系統(tǒng)是毫無設計的,這樣的系統(tǒng)有維護性和拓展性嗎?

          杜絕流水帳的編碼,使用領域模型好好規(guī)劃你的模型對象,將數(shù)據(jù)庫陰影從業(yè)務層趕出去,這是DDD試圖告訴我們的,這也是一個正確的OO系統(tǒng)應該做到的。

          strangecat2005

          發(fā)表文章: 8
          注冊時間: 2006年07月23日 07:57

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年07月27日 22:37 回復
          banq:
          其實推而廣之,我用的這個例子可以看出不少常用場景的影子,一個例子就是大數(shù)據(jù)量的瀏覽分頁。

          而你的思路恰恰是我不敢在大型項目里使用hibernate的原因:
          系統(tǒng)構架設計的時候一個重要的地方是考慮負載的分配,哪些東西在數(shù)據(jù)庫解決,哪些東西在應用程序里解決。比如,從一個List中選取一個特定的值,當然可以把數(shù)據(jù)都調進來,然后iterate中一個一個的判斷查找,也可以直接用一個select語句,從數(shù)據(jù)庫里直接把制定的結果選出來。顯然,只有合理的分配負載,系統(tǒng)才能高效的完成功能。

          但從你的思路中,全OO的一個潛在的意思就是讓hibernate去處理負載的分配問題,自己的設計完全不進行考慮。這種想法在理論上顯得漂亮,但實際用的時候,能保證效率嗎?

          banq

          發(fā)表文章: 7538
          注冊時間: 2002年08月03日 17:08

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年07月28日 17:38 回復
          >但從你的思路中,全OO的一個潛在的意思就是讓hibernate去處理負載的分配問題,自己的設計完全不進行考慮。這種想法在理論上顯得漂亮,但實際用的時候,能保證效率嗎?

          你的擔憂是非常有道理的,其實使用Hibernate 的Open Session in View只有在真正遍歷集合數(shù)據(jù)時才會讀取數(shù)據(jù)庫或緩存(如果二次以上是緩存),所以,在編程時我們回避了數(shù)據(jù)庫,實現(xiàn)分層設計目的,而在運行時,它們是混合在一起運行的,這實際已經(jīng)成為我們目前一個設計主概念,例如AOP等等都是玩這樣的把戲。

          如果理解這樣的思路,我們來對付負載就有辦法,因為首先負載是運行時的負載,根據(jù)上面運行原理得知,負載還是集中在業(yè)務層的Service上,這時我們講這些Service使用集群性質的Session Bean實現(xiàn),就解決了負載問題。

          總之一句話:分而治之!

          alexzhou

          發(fā)表文章: 3
          注冊時間: 2006年07月31日 11:03

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年07月31日 11:04 回復
          是設計要改變了,設計的過程不是一成不變的,和系統(tǒng)架構很有關系

          banq

          發(fā)表文章: 7538
          注冊時間: 2002年08月03日 17:08

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年08月03日 16:03 回復
          在現(xiàn)代系統(tǒng)設計中,數(shù)據(jù)庫影子基本看不見了。

          大家可以查看開源軟件的appFuse,在其中你都無法尋找到數(shù)據(jù)庫SQL結構,甚至找不到Hibernate Mapping文件,它們都附屬在Domain Model 對象中了。
          https://appfuse.dev.java.net/

          如果這么極端的例子無法接受,學習學習JiveJdon3,它也是一個DDD設計的案例,只是數(shù)據(jù)庫使用了以前版本的,實現(xiàn)一個過渡銜接。

          recher

          發(fā)表文章: 25
          注冊時間: 2004年02月10日 14:06

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年08月03日 17:19 回復
          我是一個hibernate的反對者,我認為hibernate是技術牛人,架構笨蛋搞出來的東西(請寬恕我的無禮,我只想引起大家的重視).我曾經(jīng)在我的blog上都批評了hibernate了幾次。我現(xiàn)在總結一下我的觀點:hibernate有三個理由我們不能覺得它是O/R mapping的企業(yè)化工具。
          第一,它不符合人類的抽象思維,hibarnate是業(yè)務操作對象-->業(yè)務信息對象-->業(yè)務信息模型(xml的描述--實際上是DBMS邏輯數(shù)據(jù)模型)。本來從業(yè)務對象一下到了表關系就很大的問題,維護開發(fā)人員必須對相應的數(shù)據(jù)模型有必須了解后才能維護。維護的風險和成本都增加了。
          第二,它回到以前的的數(shù)據(jù)庫時代,如果不使用它的HSQL的話就完全否定了DBMS 的功能的時候是一個從業(yè)務代碼抽象到數(shù)據(jù)對象的過渡(他隱藏了數(shù)據(jù)層面的業(yè)務抽象實現(xiàn)),這樣的做法并不是說不好但是必須是你隱藏的如果能100%的滿足和實現(xiàn)倒也是一個不錯節(jié)省關注了一個層面,但是實踐證明并非事事如愿的,恰恰是很多時候存在了這個DB層面業(yè)務對象(SQL)有了更合理的過渡。然而學習HSQL又是一種成本。我覺得SQL是DBMS提供出來一種面向對象抽象語言(準確的說應該是業(yè)務抽象語言)
          第三,性能,如果不使用HSQL的話,性能在維護負責的多表的時候是困難和性能是低下的。
          我覺得它和ibatis的比較,ibatis更像企業(yè)級東西。我blog上有我關于hibernate和ibatis的比較文章:http://recher.blogdriver.com/recher/1079673.html

          strangecat2005

          發(fā)表文章: 8
          注冊時間: 2006年07月23日 07:57

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年08月04日 13:21 回復
          這兩天也在繼續(xù)琢磨這個問題,思考出發(fā)點首先是懷疑:
          是我自己沒有學明白hibernate?還是hibernate本身有問題?

          首先說自己的確對hibernate所知有限,畢竟一直沒敢用它做大型項目,而只是玩了幾個小例子程序。

          但是有一點本質性的懷疑:
          如果hibernate的引入真的能完全屏蔽數(shù)據(jù)庫層,讓開發(fā)人員完全從OO角度來構建應用,那么HQL拿來做什么用?

          HQL是一個query language,和SQL層面類似。HQL引入進hibernate后,其實反而證明數(shù)據(jù)庫層的東西是不能被完全屏蔽掉的!

          recher

          發(fā)表文章: 25
          注冊時間: 2004年02月10日 14:06

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年08月04日 14:53 回復
          所以我說hibernate就是一個技術狂給我們展現(xiàn)了一個例子:因為沒有合理定位,沒有把握住架構切入點,雖然有高超的技術,弄出來的東西反而是哭笑不得的東西(說他不好嘛,他在技術實現(xiàn)上的確有很多值得我我們學習,說它好嘛但企業(yè)級應用上又有一些對系統(tǒng)生命周期有害的東西)。我覺得它根本沒有從O/R mapping在整個體系中正確定位(沒有系統(tǒng)思考問題).還有我以前接觸的項目有中型項目運用了hibernate,后果是大力理解和觀看維護關系xml---也是一個很大的風險和成本。

          totempole

          發(fā)表文章: 7
          注冊時間: 2006年09月11日 11:51

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年09月11日 11:58 回復
          HQL是object-oriented query language. Query是針對Domain object model的. 與你的relational model in DB毫無關系.
          另外, 數(shù)據(jù)庫的形式有許多種, relational, object-oriented, XML-native,berkeley database. 沒有必要局限自己在relational db的框架之中.

          strangecat2005

          發(fā)表文章: 8
          注冊時間: 2006年07月23日 07:57

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年09月15日 15:06 回復
          "HQL是object-oriented query language. Query是針對Domain object model的. 與你的relational model in DB毫無關系.
          另外, 數(shù)據(jù)庫的形式有許多種, relational, object-oriented, XML-native,berkeley database. 沒有必要局限自己在relational db的框架之中."

          Hibernate是ORM,跟“數(shù)據(jù)庫的形式有許多種”中其他形式的數(shù)據(jù)庫沒啥關系吧。

          HQL名義上是面對對象,實際使用中感覺就是把數(shù)據(jù)庫里面的列名換成了對象的property名,其他在概念上有什么區(qū)別嗎?

          totempole

          發(fā)表文章: 7
          注冊時間: 2006年09月11日 11:51

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年09月16日 11:01 回復
          使用DAO layer的目的是要分離出Data Access Code, 建立的Domain Object Model與database的類型沒有關系. 對于你的Business Tier和Presentation Tier, database的類型是完全屏蔽的.

          Domain object model in Java program與Relational model in DB可以相差很大. 你對于O/R Mapping的理解還有待提高.

          banq

          發(fā)表文章: 7538
          注冊時間: 2002年08月03日 17:08

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年09月18日 17:47 回復
          相關帖子:

          討論如何通過Hibernate提高訪問數(shù)據(jù)庫的速度
          http://www.jdon.com/jive/thread.jsp?forum=16&thread=28484

          strangecat2005

          發(fā)表文章: 8
          注冊時間: 2006年07月23日 07:57

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年09月18日 21:27 回復
          "使用DAO layer的目的是要分離出Data Access Code, 建立的Domain Object Model與database的類型沒有關系. 對于你的Business Tier和Presentation Tier, database的類型是完全屏蔽的.

          Domain object model in Java program與Relational model in DB可以相差很大. 你對于O/R Mapping的理解還有待提高. "

          像其他很多模式一樣,DAO也面臨很多爭議,到今天也非業(yè)界公認的best practice.

          O/R Mapping及其代表hibernate更不一定非要和DAO扯上關系。使用O/R Mapping完全可以不使用DAO模式。

          O/R Mapping本身就是為了彌補OO和RDB之間的語義差距,做到數(shù)據(jù)庫層對OO層業(yè)務邏輯的屏蔽。最理想的O/R Mapping應該是在RDB上,對OO各種方法論完全沒有影響。顯然,很遺憾,Hibernate沒能做到這一點。

          大家一起提高吧。

          recher

          發(fā)表文章: 25
          注冊時間: 2004年02月10日 14:06

          Re: 總覺得Hibernate影響設計思路 發(fā)表: 2006年09月21日 14:45 回復
          HSQL其實應該是內(nèi)存數(shù)據(jù)庫HSQLDB的一個部分.其實hibernate 的tale關系和過濾等操作都是經(jīng)過內(nèi)存來匹配的(JVM中),不符合宏觀的三層架構體系。

          posted on 2007-04-03 00:02 imcb 閱讀(563) 評論(0)  編輯  收藏 所屬分類: 技術討論


          只有注冊用戶登錄后才能發(fā)表評論。


          網(wǎng)站導航:
           

          導航

          統(tǒng)計

          常用鏈接

          留言簿(2)

          隨筆分類

          隨筆檔案

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 通许县| 石林| 乌兰县| 射阳县| 绥阳县| 汕头市| 琼结县| 桑植县| 正安县| 积石山| 梨树县| 宁乡县| 京山县| 潞西市| 柳江县| 长宁县| 泌阳县| 措勤县| 延安市| 阳朔县| 顺昌县| 荣成市| 安徽省| 镇坪县| 东阳市| 房山区| 富顺县| 南城县| 称多县| 临江市| 仁怀市| 阿拉尔市| 平南县| 江华| 佳木斯市| 通榆县| 武胜县| 环江| 甘德县| 阜城县| 原平市|