<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

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

    與我一起遨游吧

     

    Hibernate影響設計思路

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

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

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

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

    banq

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

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

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

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

    參考:面向ο蠓治`^程

    strangecat2005

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

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

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


    class Issue{
    ...
    List issuePropPackList;

    public IssuePropPack getCurrentIssuePropPack(){
    }

    public IssuePropPack getHistoryIssuePropPack(){
    }


    public List getHistoryPropPackList(){
    }

    }


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


    strangecat2005

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

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

    j10A

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

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

    strangecat2005

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

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

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

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



    banq

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

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

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

    因此,業務層獲得的Issue是一個完整的與數據庫無關的完全OO對象;

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

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

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

    strangecat2005

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

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

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

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

    banq

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

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

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

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

    總之一句話:分而治之!

    alexzhou

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

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

    banq

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

    Re: 總覺得Hibernate影響設計思路 發表: 2006年08月03日 16:03 回復
    在現代系統設計中,數據庫影子基本看不見了。

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

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

    recher

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

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

    strangecat2005

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

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

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

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

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

    recher

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

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

    totempole

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

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

    strangecat2005

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

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

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

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

    totempole

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

    Re: 總覺得Hibernate影響設計思路 發表: 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

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

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

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

    strangecat2005

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

    Re: 總覺得Hibernate影響設計思路 發表: 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也面臨很多爭議,到今天也非業界公認的best practice.

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

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

    大家一起提高吧。

    recher

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

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

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


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


    網站導航:
     

    導航

    統計

    常用鏈接

    留言簿(2)

    隨筆分類

    隨筆檔案

    文章檔案

    搜索

    最新評論

    閱讀排行榜

    評論排行榜

    主站蜘蛛池模板: 免费人成在线观看网站视频 | 亚洲综合激情五月色一区| 可以免费观看的毛片| 狠狠亚洲婷婷综合色香五月排名| 久久人午夜亚洲精品无码区| 一本色道久久综合亚洲精品高清| 亚洲AV日韩AV无码污污网站| 日韩精品视频免费网址| 色窝窝亚洲av网| 亚洲av成人一区二区三区在线观看 | 在线观看亚洲精品福利片| www在线观看免费视频| 亚洲人成色777777在线观看| 免费一级不卡毛片| 亚洲永久中文字幕在线| 美女视频黄免费亚洲| 亚洲国产精品无码久久98| 免费在线视频一区| a级毛片免费全部播放无码| 亚洲精品无码久久毛片波多野吉衣| 四虎在线成人免费网站| 亚洲精品无码久久久久YW| a毛片久久免费观看| 亚洲视频在线一区| 在线看片免费不卡人成视频| 久久久久久久久亚洲| 国产电影午夜成年免费视频| 久久久青草青青亚洲国产免观| 亚洲一区二区在线免费观看| 亚洲伊人久久大香线蕉影院| 免费观看国产小粉嫩喷水| 久久久精品视频免费观看| 亚洲视频在线观看地址| 性做久久久久免费看| 在线观看免费视频一区| 国产亚洲sss在线播放| 免费国内精品久久久久影院| 久久久久国产精品免费看| 亚洲爆乳成av人在线视菜奈实| 亚洲精品成人网站在线观看 | eeuss草民免费|