Hibernate的reference的副標(biāo)題叫做：符合java慣例的O/R 持久化，這揭示了目前三層結(jié)構(gòu)的重大問(wèn)題，就是三層的不統(tǒng)一。到目前為止，仍然難于在web界面上實(shí)現(xiàn)C/S模式中"master-detail"，"lookup"的快捷的用戶交互。

目前常見的web application的結(jié)構(gòu)，包含web browser/application server/database。database占據(jù)主流的仍然是經(jīng)典的E/R模型，這個(gè)模型是基于行集的，因此在vb/delphi/power builder的實(shí)踐中，data source/table set都是基于行集的，odbc/jdbc driver也都是基于行集的。view層的DbGrid也是基于行集的，和Entity模型對(duì)應(yīng)得非常好，開發(fā)簡(jiǎn)易直觀，相信這是C/S模式得到迅速推廣的重點(diǎn)原因之一。“master-detail”,"lookup"都是C/S模式下極為常見和直觀的關(guān)聯(lián)模式。

但本質(zhì)上，Object pascal/java都是面向?qū)ο蟮?。在此，就出現(xiàn)了一次重大的不統(tǒng)一：OO vs E-R。出現(xiàn)的解決方式就是EJB和O/R mapping 工具。EJB的entity bean是早期的entity封裝形式。但是和現(xiàn)在以hibernate為代表的先進(jìn)工具（對(duì)POJO執(zhí)行持久化）比較起來(lái)，在OO與ER的對(duì)應(yīng)上顯得笨重而難于使用。在這些工具中，代表OO與E-R融合的最本質(zhì)的功能則是繼承樹與表結(jié)構(gòu)的對(duì)應(yīng)關(guān)系。hibernate2支持整棵繼承樹與一個(gè)表對(duì)應(yīng)、繼承樹中每個(gè)類與一個(gè)表對(duì)應(yīng)兩種基本的對(duì)應(yīng)關(guān)系，而hibernate 3引入的join標(biāo)記則更可以將二者融合，實(shí)現(xiàn)每個(gè)類可選與基類在同一個(gè)表中持久或者在新表中保存部分持久數(shù)據(jù)，可以說(shuō)hibernate 3把這個(gè)對(duì)應(yīng)的任務(wù)完成得非常出色。"master-detail","lookup"則對(duì)應(yīng)hbm.xml這樣的映射文件中的"one-many","many-one"關(guān)聯(lián)。

database與java的融合完成之后，下一步，不可避免的就是現(xiàn)有的web client與服務(wù)器端代碼之間的融合。從表面上看，web client大多采用html/javascript完成，而服務(wù)器端采用java輸出，二者是簡(jiǎn)單的命令/反饋的模型，這個(gè)模型從model 1發(fā)展到MVC的模型后，編寫代碼變得清晰，但是開發(fā)人員仍然發(fā)現(xiàn)，編寫web app仍然不是一件簡(jiǎn)單的事情。struts/webwork仍然只是非常底層的基礎(chǔ)，對(duì)編寫客戶端業(yè)務(wù)對(duì)象沒有什么幫助。比如說(shuō),在服務(wù)器端java程序建模時(shí)，大家已經(jīng)習(xí)慣用pojo分析訂單/客戶/產(chǎn)品，但是在編寫web client時(shí)，struts/webwork都只能幫助你完成頁(yè)面提交/反饋的流程，卻不能幫助你分析客戶端業(yè)務(wù)：新建訂單時(shí)，選擇了客戶之后，判斷此客戶是否有足夠的預(yù)收款，這樣一個(gè)簡(jiǎn)單用例在程序員心目中的反映仍然是每個(gè)字段的input tag,每個(gè)頁(yè)面post上來(lái)的model,以及如何用action的處理再次渲染下一個(gè)頁(yè)面。

最大的問(wèn)題，就是作為表現(xiàn)層的web client端代碼與服務(wù)器端代碼蘊(yùn)含的語(yǔ)義脫節(jié)。具體表現(xiàn)在：
 在采用struts/webwork這樣的MVC結(jié)構(gòu)的時(shí)候，通常不會(huì)考慮在客戶端進(jìn)行業(yè)務(wù)控制，比如由javascipt判斷預(yù)收款是否足夠。因此需要不斷的多次頁(yè)面刷新才能完成整個(gè)邏輯。

要解決此問(wèn)題，通常可以采用把業(yè)務(wù)邏輯部分轉(zhuǎn)移到客戶端，以javascript + xmlhttp或javascript + web service,java applet/application,甚至采用office平臺(tái)(嵌入代碼到excel)完成整個(gè)業(yè)務(wù)邏輯。也有很多問(wèn)題：

1，若要在客戶端實(shí)現(xiàn)業(yè)務(wù)邏輯，可能客戶端代碼沒有對(duì)應(yīng)Pojo這樣的基礎(chǔ)object設(shè)施。javascript缺乏如interface這樣的基礎(chǔ)結(jié)構(gòu)。excel方案在這點(diǎn)更加難于進(jìn)行，因?yàn)檎麄€(gè)開發(fā)涉及到的語(yǔ)言太多，造成開發(fā)難度加大，項(xiàng)目控制困難。
直接后果就是，難于在客戶端代碼中定義"master-detail","lookup"等關(guān)聯(lián)。就算在項(xiàng)目規(guī)劃中在javascript中定義pojo(plain old javascript object)及其關(guān)聯(lián)，也難于利用hbm.xml這樣的現(xiàn)成關(guān)聯(lián)描述。

2，客戶端基礎(chǔ)設(shè)施難于進(jìn)行界面元素綁定。在處理大量數(shù)據(jù)時(shí)，excel方案在此體現(xiàn)出杰出的優(yōu)勢(shì)，客戶對(duì)內(nèi)置程序的excel的接受程度非常高，但缺點(diǎn)是這種excel程序難于做到xmlhttp可以輕松做到的動(dòng)態(tài)查詢等特性。

3，客戶端基礎(chǔ)設(shè)施難于與服務(wù)器端進(jìn)行交互。xmlhttp以及web service可選，但是在企業(yè)應(yīng)用中其低下效率可能會(huì)帶來(lái)服務(wù)器的壓力隱患，降低性能和吞吐量。若excel方案，則同樣面臨著與服務(wù)器數(shù)據(jù)交互的難題。不管是xmlhttp方案還是application方案，都面臨著拋棄struts/webwork重新實(shí)現(xiàn)request/response dispatch的要求。

4，客戶端基礎(chǔ)設(shè)施難于進(jìn)行單元測(cè)試。有junit4js，port了junit 3.8.1，但沒有成熟的stub/mock工具。excel方案在此幾乎不可測(cè)試。

5, 客戶端基礎(chǔ)設(shè)施難于調(diào)試。javascript缺乏類似log4j這樣的log工具(log4js http://www./Programmes/jslib.htm 這樣的工具還遠(yuǎn)沒有成熟)，也難于進(jìn)行斷點(diǎn)跟蹤。excel方案倒是有完整的vba環(huán)境。

6, 客戶端基礎(chǔ)設(shè)施運(yùn)行效率低。javascipt/vba都是解釋語(yǔ)言，難于實(shí)現(xiàn)復(fù)雜邏輯，其性能決定只能用它們進(jìn)行細(xì)粒度的界面控制。

7，由于瀏覽器的分裂，造成語(yǔ)言的不標(biāo)準(zhǔn)，應(yīng)用程序難以跨平臺(tái)使用。在IE平臺(tái)上可以使用behavior和expression這種類AOP的操作，卻無(wú)法在mozilla中實(shí)現(xiàn)。

jsf方案有望成為備選方案，但是按照myfaces目前的情況，要實(shí)現(xiàn)更多的表現(xiàn)層控件，才能完成更復(fù)雜靈活的控制。

下面一次軟件開發(fā)方式的突破，向前看，可能出現(xiàn)設(shè)計(jì)方式的突破，MDA是方向；另一個(gè)方向就是向后對(duì)具體實(shí)現(xiàn)的突破，在類似webapp這樣的具體技術(shù)（除了webapp,application同樣面臨類似問(wèn)題）上，對(duì)于是否能夠把model的定義直接帶入到表現(xiàn)層，JSF和.NET可能會(huì)有新一輪競(jìng)爭(zhēng)。