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