Hibernate的reference的副標題叫做：符合Java慣例的O/R 持久化，這揭示了目前三層結構的重大問題，就是三層的不統一。到目前為止，仍然難於在web界面上實現C/S模式中"master-detail"，"lookup"的快捷的用戶交互。
目前常見的web application的結構，包含web browser/application server/database。database占據主流的仍然是經典的E/R模型，這個模型是基於行集的，因此在vb/Delphi/power builder的實踐中，data source/table set都是基於行集的，odbc/jdbc driver也都是基於行集的。vIEw層的DbGrid也是基於行集的，和Entity模型對應得非常好，開發簡易直觀，相信這是C/S模式得到迅速推廣的重點原因之一。“master-detail”,"lookup"都是C/S模式下極為常見和直觀的關聯模式。
但本質上，Object pascal/Java都是面向對象的。在此，就出現了一次重大的不統一：OO vs E-R。出現的解決方式就是EJB和O/R mapping 工具。EJB的entity bean是早期的entity封裝形式。但是和現在以hibernate為代表的先進工具（對POJO執行持久化）比較起來，在OO與ER的對應上顯得笨重而難於使用。在這些工具中，代表OO與E-R融合的最本質的功能則是繼承樹與表結構的對應關系。hibernate2支持整棵繼承樹與一個表對應、繼承樹中每個類與一個表對應兩種基本的對應關系，而hibernate 3引入的join標記則更可以將二者融合，實現每個類可選與基類在同一個表中持久或者在新表中保存部分持久數據，可以說hibernate 3把這個對應的任務完成得非常出色。"master-detail","lookup"則對應hbm.XML這樣的映射文件中的"one-many","many-one"關聯。
database與java的融合完成之後，下一步，不可避免的就是現有的web clIEnt與服務器端代碼之間的融合。從表面上看，web clIEnt大多采用Html/Javascript完成，而服務器端采用java輸出，二者是簡單的命令/反饋的模型，這個模型從model 1發展到MVC的模型後，編寫代碼變得清晰，但是開發人員仍然發現，編寫web app仍然不是一件簡單的事情。struts/webwork仍然只是非常底層的基礎，對編寫客戶端業務對象沒有什麼幫助。比如說,在服務器端Java程序建模時，大家已經習慣用pojo分析訂單/客戶/產品，但是在編寫web clIEnt時，struts/webwork都只能幫助你完成頁面提交/反饋的流程，卻不能幫助你分析客戶端業務：新建訂單時，選擇了客戶之後，判斷此客戶是否有足夠的預收款，這樣一個簡單用例在程序員心目中的反映仍然是每個字段的input tag,每個頁面post上來的model,以及如何用action的處理再次渲染下一個頁面。
最大的問題，就是作為表現層的web clIEnt端代碼與服務器端代碼蘊含的語義脫節。具體表現在： 在采用struts/webwork這樣的MVC結構的時候，通常不會考慮在客戶端進行業務控制，比如由Javascipt判斷預收款是否足夠。因此需要不斷的多次頁面刷新才能完成整個邏輯。
要解決此問題，通常可以采用把業務邏輯部分轉移到客戶端，以Javascript + XMLhttp或Javascript + web service,Java applet/application,甚至采用Office平台(嵌入代碼到Excel)完成整個業務邏輯。也有很多問題：
1，若要在客戶端實現業務邏輯，可能客戶端代碼沒有對應Pojo這樣的基礎object設施。javascript缺乏如interface這樣的基礎結構。Excel方案在這點更加難於進行，因為整個開發涉及到的語言太多，造成開發難度加大，項目控制困難。直接後果就是，難於在客戶端代碼中定義"master-detail","lookup"等關聯。就算在項目規劃中在Javascript中定義pojo(plain old Javascript object)及其關聯，也難於利用hbm.XML這樣的現成關聯描述。
2，客戶端基礎設施難於進行界面元素綁定。在處理大量數據時，excel方案在此體現出傑出的優勢，客戶對內置程序的excel的接受程度非常高，但缺點是這種Excel程序難於做到XMLhttp可以輕松做到的動態查詢等特性。
3，客戶端基礎設施難於與服務器端進行交互。xmlhttp以及web service可選，但是在企業應用中其低下效率可能會帶來服務器的壓力隱患，降低性能和吞吐量。若Excel方案，則同樣面臨著與服務器數據交互的難題。不管是XMLhttp方案還是application方案，都面臨著拋棄struts/webwork重新實現request/response dispatch的要求。
4，客戶端基礎設施難於進行單元測試。有junit4JS，port了junit 3.8.1，但沒有成熟的stub/mock工具。Excel方案在此幾乎不可測試。
5, 客戶端基礎設施難於調試。Javascript缺乏類似log4j這樣的log工具(log4js http://www.petrusrex.com/Programmes/JSlib.htm 這樣的工具還遠沒有成熟)，也難於進行斷點跟蹤。Excel方案倒是有完整的vba環境。
6, 客戶端基礎設施運行效率低。Javascipt/vba都是解釋語言，難於實現復雜邏輯，其性能決定只能用它們進行細粒度的界面控制。
7，由於浏覽器的分裂，造成語言的不標准，應用程序難以跨平台使用。在IE平台上可以使用behavior和expression這種類AOP的操作，卻無法在mozilla中實現。
JSf方案有望成為備選方案，但是按照myfaces目前的情況，要實現更多的表現層控件，才能完成更復雜靈活的控制。
下面一次軟件開發方式的突破，向前看，可能出現設計方式的突破，MDA是方向；另一個方向就是向後對具體實現的突破，在類似webapp這樣的具體技術（除了webapp,application同樣面臨類似問題）上，對於是否能夠把model的定義直接帶入到表現層，JSF和.Net可能會有新一輪競爭。
