程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> JAVA編程 >> J2EE >> 結合struts和hibernate談J2EE架構的數據表示

結合struts和hibernate談J2EE架構的數據表示

編輯:J2EE
在 struts+ hibernate 這種結構中,是不應該把Hibernate產生的PO直接傳遞給JSP的,不管他是Iterator,還是List,這是一個設計錯誤。 我來談談在J2EE架構中各層的數據表示方法: Web層的數據表示是FormBean,數據來源於HTML Form POST 業務層的數據表示是VO 持久層的數據表示是PO,其數據來源於數據庫,持久層的數據表示例如CMP 在一個規范的J2EE架構中,不同層的數據表示應該被限制在層內,而不應該擴散到其它層,這樣可以降低層間的耦合性,提高J2EE架構整體的可維護性和可擴展性。比如說Web層的邏輯進行了修改,那麼只需要修改FormBean的結構,而不需要觸動業務層和持久層的代碼修改。同樣滴,當數據庫表進行了小的調整,那麼也只需要修改持久層數據表示,而不需要觸動業務層代碼和Web層代碼。 不過由於Hibernate的強大功能,例如動態生成PO,PO的狀態管理可以脫離Session,使得在應用了Hibernate的J2EE框架中,PO完全可以充當VO,因此我們下面把PO和VO合並,統稱為PO。 先來談談ActionFormBean和持久層的PO之間的重大區別: 在簡單的應用中,ActionFormBean和PO幾乎是沒有區別,所以很多人干脆就是用ActionFormBean來充當PO,於是ActionFormBean從JSP頁面到Servlet控制層再到業務層,然後穿過持久層,最後一直映射到數據庫表。真是一竿子捅到了底! 但是在復雜的應用中,ActionFormBean和PO是分離的,他們也不可能一樣。ActionFormBean是和網頁裡面的Form表單一一對應的,Form裡面有什麼元素,Bean裡面就有什麼屬性。而PO和數據庫表對應,因此如果數據庫表不修改,那麼PO也不會修改,如果頁面的流程和數據庫表字段對應關系不一致,那麼你又如何能夠使用ActionFormBean來取代PO呢? 比如說吧,用戶注冊頁面要求注冊用戶的基本信息,因此Html Form裡面包含了基本信息屬性,於是你需要一個ActionFormBean來一一對應(注意:是一一對應),每個Bean屬性對應一個文本框或者選擇框什麼的。 而用戶這個持久對象呢?他的屬性和ActionFormBean有什麼明顯不同呢?他會有一些ActionFormBean所沒有的集合屬性,比如說用戶的權限屬性,用戶的組屬性,用戶的帖子等等。另外還有可能的是在ActionFormBean裡面有3個屬性,分別是用戶的First Name, Middle Name, Last Name,而在我的User這個持久對象中就是一個 Name 對象屬性。 假設我的注冊頁面原來只要你提供First Name,那麼ActionFormBean就這一個屬性,後來我要你提供全名,你要改ActionFormBean,加兩個屬性。但是這個時候PO是不應該修改滴,因為數據庫沒有改。 那麼在一個完整的J2EE系統中應該如何進行合理的設計呢? JSP(VIEw) ---> Action Form Bean (Module) ---> Action(Control) Action Form Bean是Web層的數據表示,它和Html頁面Form對應,只要Web頁面的操作流程發生改變,它就要相應的進行修改,它不應該也不能被傳遞到業務層和持久層,否則一旦頁面修改,會一直牽連到業務層和持久層的大面積的代碼進行修改,對於軟件的可維護性和可擴展性而言,是一個災難,Actiont就是他的邊界,到此為止! Action(Web Control) ---> Business Bean ---> DAO ---> ORM --->DB 而PO則是業務層和持久層的數據表示,它在業務層和持久層之間進行流動,他不應該也不能被傳遞到Web層的VIEw中去,而ActionServlet就是他的邊界,到此為止! 然後來看一看整個架構的流程: 當用戶通過浏覽器訪問網頁,提交了一個頁面。於是Action拿到了這個FormBean,他會把FormBean屬性讀出來,然後構造一個PO對象,再調用業務層的Bean類,完成了注冊操作,重定向到成功頁面。而業務層Bean收到這個PO對象之後,調用DAO接口方法,進行持久對象的持久化操作。 當用戶查詢某個會員的信息的時候,他用全名進行查詢,於是Action得到一個UserNameFormBean包括了3個屬性,分別是first name, middle name, last name,然後Action把UserNameFormBean的3個屬性讀出來,構造Name對象,再調用業務Bean,把Name對象傳遞給業務Bean,進行查詢。 業務Bean取得Name(注意: Name對象只是User的一個屬性)對象之後調用DAO接口,返回一個User的PO對象,注意這個User不同於在Web層使用的UserFormBean,他有很多集合屬性滴。然後業務Bean把User對象返回給Action。 Action拿到User之後,把User的基本屬性取出(集合屬性如果不需要就免了),構造UserFormBean,然後把UserFormBean request.setAttribute(...),然後重定向到查詢結果頁面。 查詢頁面拿到request對象裡面的ActionFormBean,自動調用tag顯示之。 總結: Form Bean 是Web層的數據表示,他不能被傳遞到業務層;PO是持久層的數據表示,在特定情況下,例如Hibernate中,他可以取代VO出現在業務層,但是不管PO還是VO都必須限制在業務層內使用,最多到達Web層的Control,絕不能被擴散到VIEw去。 Form Bean 和PO之間的數據轉化是在Action中進行滴。 BTW: JDO1.x還不能像Hibernate功能這樣強大,PO不能脫離持久層,所以必須在業務層使用VO,因此必須在業務層進行大量的VO和PO的轉化操作,相對於Hibernate來說,編程比較煩瑣。 當然咯,理論是一回事,實際操作也不一定非要這樣干,你可以自行取捨,在實際項目中靈活一點,增加一點bad smell,提高開發效率。只不過在大型項目中最好還是嚴絲合縫,不然的話,改版的時候會痛苦的很滴。
  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved