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