建站
咨詢
售后
建站咨詢
新聞中心
Java EE是個相當(dāng)復(fù)雜的東西，被很多開發(fā)者們視為龐然大物。在下面的文章中，javaonejcy探討了如何簡化Java EE開發(fā)中不必要的復(fù)雜，并給出一個不使用任何框架的架構(gòu)模型。
你可以說可愛的php ，可愛的ror ，可愛的python ，甚至可愛的.net ，但是Java EE ？他太復(fù)雜了。相比其他兩種技術(shù)，Java EE 的技術(shù)體系更全面、更規(guī)整也更復(fù)雜，他的復(fù)雜性也讓很多廠商望而止步，寧可選擇簡單甚至簡陋的php ，這充分說明快速開發(fā)是這個時代最迫切的需求。
Java EE 的servlet 、javabean 、jdbc 規(guī)范給了我們組件和容器的唯一標(biāo)準(zhǔn)，而更高級的支持，jsf 、jdo 規(guī)范卻沒能給予我們唯一的框架級標(biāo)準(zhǔn)，他們被認(rèn)可的程度遠(yuǎn)低于相同領(lǐng)域的開源框架。盡管開源社區(qū)給了我們最豐富的選擇，但是相比.net 、php 、ror 的全棧式服務(wù)，Java EE 開發(fā)者必須DIY 。DIY 不但需要時間而且需要冒險，這種發(fā)燒友做的事情是企業(yè)所不愿意做的。一段時間以來，公司Java EE 方向的招聘幾乎清一色的要求struts 、spring 、hibernate 這幾種主流框架的能力就是一種證明。
Java EE 的開發(fā)往往避免不了配置之旅，盡管很多框架都有自動生成工具，但是，面對一個中型項目，仍然容易造成混亂。配置使你無論在開發(fā)、測試、集成還是維護的時都要配置代碼兩頭看。配置給了框架一個注入服務(wù)的切入點，但是對人并無優(yōu)雅可言。ror 給了我們啟發(fā)，盡管企業(yè)開發(fā)是復(fù)雜的，但是大多數(shù)的需求都是通用的，事實證明，ror 把這部分通用性用約定的方式抽象得很好。其實Java EE 并不缺乏約定，因為他本身就是建立于一系列規(guī)范的基礎(chǔ)之上，而規(guī)范就是約定。所以，Java EE 實際上有機會成為相對簡潔的開發(fā)技術(shù)，只不過由于種種原因，這種規(guī)范并未出現(xiàn)。
在眾多的Java EE 開發(fā)框架中，struts+spring+hibernate 有著黃金組合的美譽，用的人多，會的人多，就算是沒出校門的學(xué)生，也知道學(xué)會ssh 的重要性。但是學(xué)會和學(xué)懂是兩碼事，對于一個中型項目，ssh 就成了一柄雙刃劍，需要由高水平的設(shè)計師引路，才能披荊斬棘。spring+hibernate 給了設(shè)計者廣闊的空間，而設(shè)計需要因項目的前進(jìn)而演進(jìn)，如果你的項目進(jìn)度緊張，人手不足，設(shè)計質(zhì)量就難以保障，給系統(tǒng)帶來隱患。
“任何優(yōu)秀的語言，都可以幫助開發(fā)者寫出優(yōu)秀的代碼，但不能阻止開發(fā)者寫出糟糕的代碼”。在這一點上，無論是Java EE ，.net ，ror ，php 都不會例外。而開發(fā)框架就像是“一間有很多屋梁的房子”，“框架的強大之處不是他能讓你做什么，而是他不能讓你做什么”，其實如同語言一樣，框架雖然可以給予開發(fā)一定程度的規(guī)范指導(dǎo)，但是這種指導(dǎo)仍然是有限的，這真應(yīng)了那句老話：事在人為。
本文試圖探討如何簡化Java EE 開發(fā)中不必要的復(fù)雜，并給出的是一個不使用任何框架的架構(gòu)模型，讓我們看看僅僅通過用編碼約定，結(jié)構(gòu)設(shè)計和使用方式的組合能不能滿足項目開發(fā)的主要需求— 短期培訓(xùn)，降低隱患和快速開發(fā)。
問題的源頭
應(yīng)用軟件開發(fā)是復(fù)雜的，但其基本模型至為簡單，請求－處理－響應(yīng)。對應(yīng)于軟件的層次結(jié)構(gòu)就是：請求－Cortrol （C ）；處理－Model （M ）；響應(yīng)－View （V ）。在早期的Java EE 應(yīng)用中，servlet 負(fù)責(zé)C ，javabean 和jdbc 在M ，jsp 是V 。這些就是Java EE 的基礎(chǔ)設(shè)施，他們職責(zé)劃分的方式被稱為JSP Model2 ，已經(jīng)可以滿足web 開發(fā)的基本需要，Java EE 的開發(fā)始終都圍繞著這幾項主要技術(shù)，框架也不例外。以下的內(nèi)容，將從這些技術(shù)的應(yīng)用與不足說起，然后介紹主流框架的解決方案，之后再介紹我們不用框架的處理方式。
(C) 選擇控制器
基礎(chǔ)規(guī)范的不足
任何web 應(yīng)用，處理請求之后返回響應(yīng)是必須的環(huán)節(jié)，如果編碼規(guī)范，傳統(tǒng)的響應(yīng)就是轉(zhuǎn)向到某個頁面，servlet 處理轉(zhuǎn)向有兩種方式，其中request 轉(zhuǎn)向隱藏著重復(fù)提交的問題，response 重定向帶來參數(shù)傳遞的編碼解碼的問題，同時眾多的轉(zhuǎn)向地址直接寫在servlet 中也十分不雅，另外，jsp 和javabean 有一種出色的關(guān)聯(lián)技術(shù)，就是在jsp 里可以把來自請求表單的數(shù)據(jù)自動拼裝到j(luò)avabean 中。糟糕的是，這么有用的技術(shù)卻無法在servlet 中使用，所以Model2 缺乏對表單數(shù)據(jù)的自動轉(zhuǎn)換處理。servlet 有這些不足很好理解，因為servlet 畢竟是較早出現(xiàn)的技術(shù)，他的職責(zé)只是將（http ）請求轉(zhuǎn)化為面向?qū)ο蟮囊晥D和輸出響應(yīng)而已，由于他是低階組件，所以部分功能的缺失是正常的。不過這就讓servlet 成為了Model2 最薄弱的一環(huán)。
開發(fā)框架的解決方案
由于以上需求是共性的，所以編寫一個通用框架就成為了很多人努力的事情，struts 很快推出并且很快流行。我們先來看一看struts 的特性：
前端控制器： struts 使用一個servlet 作為前端控制器，所有請求先經(jīng)過這里，再分派給配置指定的action （這里是指行為，而不是具體的Action ），意圖是以一個中間層將視圖層和控制層解耦，這種思路帶來了三種可能的好處：1 視圖和控制分離，所以可以選擇不同的視圖技術(shù)，比如視圖模板既可以用jsp ，也可以用Volecity 、FreeMarker ；2 可以對所有請求預(yù)處理，和后處理（webwork ）；3 可以將響應(yīng)的轉(zhuǎn)向地址管理起來。前端控制器也存在一種直接的不足：配置繁瑣。
ActionForm ： struts 主要是一個控制層框架，所以他并不意圖深入到模型層，ActionForm 是一種無奈的選擇，盡管提供了表單數(shù)據(jù)到j(luò)avabean 的轉(zhuǎn)換，但是遺憾的是這個javabean 并不能直接使用，還要手工的轉(zhuǎn)換為模型javabean ，使得ActionForm 的位置有些尷尬。
國際化支持、標(biāo)簽庫和全局異常： 國際化和標(biāo)簽庫都是struts 的亮點，不過全局異常作用有限。
我們的選擇
Java EE 的控制器必然是一個servlet ，我們也不能例外，因為我們必須要運行在servlet 容器之中。不過，我們選擇的是servlet 的演進(jìn)版本－jsp 。別誤會，我們并不是要退回到JSP Model1 。一個典型的示例是，如果我有一個員工信息錄入的功能點，那么為了實現(xiàn)這個功能，我可以建立下面兩個文件：
worker_input.jsp
worker_inputOper.jsp
worker_input.jsp 里不寫控制代碼，worker_inuptOper.jsp 里也不寫視圖代碼，這種用法實際是JSP Model1 和JSP Model2 的綜合體。這樣做最大的好處就是，免去配置的煩惱，但是等等.. 前端控制器呢？我們的中間層呢？
考慮一下，你有一個企業(yè)信息的表單，表單中有一個企業(yè)名稱域，對這個域的要求是不能在已有企業(yè)中重名，域旁邊有一個按鈕，業(yè)務(wù)員可以通過點擊這個按鈕獲得錄入企業(yè)名稱是否重復(fù)的提示。如果是傳統(tǒng)方式，點擊按鈕將導(dǎo)致一個頁面提交，如果用struts ，將要配置這個action 處理之后轉(zhuǎn)向的URL 地址，這就是傳統(tǒng)web 應(yīng)用的響應(yīng)方式- 基于URL 地址的頁面導(dǎo)航。
web2.0 來了，ajax 來了，異步請求的出現(xiàn)徹底顛覆了傳統(tǒng)的web 交互模型。對于ajax 應(yīng)用而言，服務(wù)器端返回響應(yīng)只需要out.print ，請求從哪來，回哪去，轉(zhuǎn)向（如果需要）和更新視圖的任務(wù)都交給了客戶端腳本，也就是說，基于異步交互模式的web 應(yīng)用，根本就沒有需要配置的result URL 路徑。這樣，頁面導(dǎo)航的問題就自動解決了。而對于預(yù)處理，我們可以用filter 替代。所以，我們完全可以和前端控制器說：再見。
由于客戶端技術(shù)的趨勢，在webappdemo 中我們將全面使用ajax 。也許你會說，如果客戶端瀏覽器禁用腳本呢？這個擔(dān)心在如今已經(jīng)沒有必要，你可以訪問開心或者當(dāng)當(dāng)，看看禁用腳本他們能不能工作。時代在進(jìn)步，富客戶RIA 是必然的選擇。
使用jsp 作為控制器，還使我們得到了另一個關(guān)鍵的特性，那就是從form 表單數(shù)據(jù)到j(luò)avabean 的自動創(chuàng)建和輸入，使javabean 本身既是模型也是DTO ，再也不必象ActionForm 那樣還要手工轉(zhuǎn)換。這里還有一個隱含的好處，就是強制統(tǒng)一了表單域名和模型屬性名，不然，有可能出現(xiàn)這樣的情況：表單域：child_center ；模型屬性：branch 。以下是worker_inputOper.jsp 的寫法：
Jsp代碼
- < jsp:useBean id="worker" class="webappdemo.worker.entity.Worker" scope="page"/>
- < jsp:setProperty name="worker" property="*"/>
- < %
- response.setContentType("text/x-json;charset=UTF-8");
- response.setHeader("Cache-Control", "no-cache");
- String method = request.getParameter("method");
- if("save".equals(method)){
- EntityService es = new EntityService();
- Message m = es.add(worker);
- out.print(new JSONObject().put(m.isSucceed()?"succeed":"error", m.getMessage()));
- return;
- }
- %>
可以看出，只需將實體類名引入標(biāo)簽，我們就可以獲得自動拼裝的Worker 對象。對于復(fù)雜對象或復(fù)合對象，由于request 里同樣有我們需要的所有請求參數(shù)，所以你可以在自動創(chuàng)建的javabean 基礎(chǔ)上修改部分屬性，以符合業(yè)務(wù)需要。
代碼還展示了基于“method ”的用法，這只是一個字符串，用來告訴oper jsp 要用哪個方法來處理請求，這類似于ror 控制器內(nèi)部定義的方法以及struts 的DispatchAction 但比他更靈活，變通的解決了jsp 的請求不能直接面向方法的不足。
在調(diào)用服務(wù)處理請求之后，worker_inputOper.jsp 將處理結(jié)果out.print 回客戶端，這句代碼的意思是新建一個JSON 對象，將處理結(jié)果添加進(jìn)去，然后輸出這個對象，方便客戶端js 腳本解析。JSON 對象可以增加多個處理結(jié)果，只要他們的key 不同就可以。在實際應(yīng)用中，往往返回處理消息，或者h(yuǎn)tml 視圖的字符串。最后別忘了return; 否則程序仍然會向下進(jìn)行。
如果你的項目需要國際化，我們可以使用fmt 標(biāo)簽，而對于反饋消息的國際化，我們也許就需要建立一個全局MessageSource 對象了，這個問題在webappdemo 中沒有涉及，因為筆者認(rèn)為這不是普遍需求。
對于異常處理，其實jsp 已經(jīng)提供了簡單的機制，我們可以在web.xml 中配置：
Xml代碼
- < error-page>
- < error-code>404< /error-code>
- < location>/404.jsp< /location>
- < /error-page>
- < error-page>
- < error-code>500< /error-code>
- < location>/500.jsp< /location>
- < /error-page>
這種簡單的處理其實正是我們需要的全部，因為筆者認(rèn)為，web 應(yīng)用的系統(tǒng)錯誤和java 的異常沒有區(qū)別，即檢測錯誤和運行時錯誤。在web2.0 時代，所有的錯誤都應(yīng)該被捕獲，并且把內(nèi)容經(jīng)處理后在用戶輸入位置反饋給用戶，而不應(yīng)該重新定向。運行時錯誤屬于系統(tǒng)bug ，是需要修復(fù)的代碼級錯誤，這種錯誤是真正的“意外”，所以我們用定制的錯誤頁面反饋給用戶就可以了。
綜上所述，我們用ajax+jsp+ 控制jsp 的方式代替了servlet 或者action ，擺脫了前端控制器，用模型javabean 代替了過程javabean ActionForm ，這些使用方式使我們不需要配置即可以開發(fā)應(yīng)用程序，除了ajax 是相對新概念外不需要額外學(xué)習(xí)框架技術(shù)也是他的優(yōu)點。
(M)ORM 可以做什么
基礎(chǔ)規(guī)范的不足
jdbc 是java 應(yīng)用程序數(shù)據(jù)持久化的基礎(chǔ)，也是眾多數(shù)據(jù)庫廠商與java 的接口。直接使用jdbc 編寫代碼非常繁瑣，比如數(shù)據(jù)庫資源的獲得和釋放，異常捕獲和事務(wù)處理等等，重復(fù)代碼多是他的一個特點。另外，不同的數(shù)據(jù)庫，在數(shù)據(jù)類型，主鍵類型還是sql 語句都和SQL 標(biāo)準(zhǔn)小有出入，所以如何使應(yīng)用程序可以在不同數(shù)據(jù)庫平臺方便的遷移，也是個問題。
開發(fā)框架的解決方案
spring 和hibernate 的出現(xiàn)使情況大為好轉(zhuǎn)，spring 面向切面管理事務(wù)， hibernate 自動ORM 可以大大簡化開發(fā)，spring 和hibernate 都有.net 的版本，這證明了他們的成功。但是“用好hibernate ，需要扎實的掌握關(guān)系模型和SQL ”，同時對面向?qū)ο笤O(shè)計和hibernate 自身的運行機制也要有非常清晰的認(rèn)識，只有這種水平才能發(fā)揮hibernate 的威力，降低hibernate 帶來的風(fēng)險。所以，在合適的層面上配置好spring 的事務(wù)管理，設(shè)計好對象模型，把對hibernate 的直接使用控制在一定范圍內(nèi)是設(shè)計者要解決的基本問題。如果設(shè)計不佳，或者直接交給初出校門的開發(fā)者去用，那這種組合就會變成洪水猛獸，同時也不利于團隊成員的成長。
我們的選擇
如果只有jdbc ，我們的系統(tǒng)也可以工作，只不過要寫很多重復(fù)和機械的代碼，通過框架的ORM 的映射，可以將數(shù)據(jù)庫表的數(shù)據(jù)自動填入javabean ，這節(jié)省了勞動力，也使系統(tǒng)結(jié)構(gòu)自然清晰。如果不用ORM 工具，我們能不能通過某種形式來模擬他的行為呢？我們可以創(chuàng)建這樣一個接口：
Java代碼
- public interface IOper {
- boolean load(Connection connect) throws SQLException;
- boolean add(Connection connect) throws SQLException;
- boolean update(Connection connect) throws SQLException;
- boolean delete(Connection connect) throws SQLException;
- }
在接口中定義 CRUD 方法。返回類型為 boolean 而非影響的行數(shù)，意圖是對象內(nèi)部的操作可能是復(fù)雜的多步驟的，所以對他的上層應(yīng)用來說，知道結(jié)果成功與否就可以了。接下來在他的實現(xiàn)類里可以這么寫：
Java代碼
- public class Worker implements IOper {
- // Fields
- private Integer workerId;
- private String workerName;
- private String logonName;
- private String logonPwd;
- /*
- * 對于允許為空的字段賦予初始值，避免頁面顯示null
- */
- private String mobile = "";
- private String email = "";
- private String remark = "";
- private String isFreeze = "0";
- // Constructors
- /** default constructor */
- // Property accessors
- public boolean add(Connection connect) throws SQLException {
- SQLBuffer sql = new SQLBuffer();
- sql.segment("insert into worker (worker_name,logon_name,logon_pwd,");
- sql.segment("mobile,email,remark,is_freeze) values (");
- sql.value(this.workerName);
- sql.comma();
- sql.value(this.logonName);
- sql.comma();
- sql.value(this.logonPwd);
- sql.comma();
- sql.value(this.mobile);
- sql.comma();
- sql.value(this.email);
- sql.comma();
- sql.value(this.remark);
- sql.comma();
- sql.value(this.isFreeze);
- sql.segment(")");
- return Proxy.update(connect, sql) == 1;
- }
- public boolean delete(Connection connect) throws SQLException {
- // 凍結(jié)用戶
- SQLBuffer sql = new SQLBuffer();
- sql.segment("update worker set is_isfreeze = ");
- this.isFreeze = "1";
- sql.value(this.isFreeze);
- sql.segment(" where worker_id = ");
- sql.value(this.workerId);
- return Proxy.update(connect, sql) == 1;
- }
- public boolean load(Connection connect) throws SQLException {
- SQLBuffer sql = new SQLBuffer(
- "select worker_name,logon_name,logon_pwd,mobile,email,remark,is_freeze from worker");
- sql.segment(" where worker_id = ");
- sql.value(this.workerId);
- MapRow mr = Proxy.getMapRow(connect, sql);
- if (mr == null) {
- return false;
- }
- this.workerName = mr.getString("worker_name");
- this.logonName = mr.getString("logon_name");
- this.logonPwd = mr.getString("logon_pwd");
- this.mobile = mr.getString("mobile");
- this.email = mr.getString("email");
- this.remark = mr.getString("remark");
- this.isFreeze = mr.getString("is_freeze");
- return true;
- }
- public boolean update(Connection connect) throws SQLException {
- SQLBuffer sql = new SQLBuffer();
- sql.segment("update worker set worker_name = ");
- sql.value(this.workerName);
- sql.segment(", logon_name = ");
- sql.value(this.logonName);
- sql.segment(", logon_pwd = ");
- sql.value(this.logonPwd);
- sql.segment(", mobile = ");
- sql.value(this.mobile);
- sql.segment(", email = ");
- sql.value(this.email);
- sql.segment(", remark = ");
- sql.value(this.remark);
- sql.segment(", is_freeze = ");
- sql.value(this.isFreeze);
- sql.segment(" where worker_id = ");
- sql.value(this.workerId);
- return Proxy.update(connect, sql) == 1;
- }
- }
實體 javabean 通過實現(xiàn) IOper 接口，負(fù)責(zé)對自身數(shù)據(jù)的操作。盡管這種實現(xiàn)方式等于是使模型成為了富血模型，但其實我們?nèi)匀豢梢园堰@種模型認(rèn)為是貧血的，因為他沒有業(yè)務(wù)邏輯，只是模擬了 ORM 的行為。 如果對象關(guān)系有包含和聚合，我們同樣也可以通過類似 hibernate 的行為方式來實現(xiàn)，比如懶加載。以上的代碼使用了筆者所用的 API ，由于操作都在內(nèi)部，所以換成直接用 jdbc 也是一樣的。在實際應(yīng)用中， load 方法有些單薄，因為有的查詢需要一些附加條件，我們可以通過增加一個類屬性來達(dá)到這個目的：
String condition;
如果設(shè)置了條件，我們就拼接給定的查詢條件取得結(jié)果，不過結(jié)果只能是一條，這是模型結(jié)構(gòu)所決定的。另外Connection 對象是每個方法的必須的參數(shù)，意圖是在實際業(yè)務(wù)操作中，單一的操作往往是不存在的，所以，總是由外部傳遞資源和釋放資源。但是，在每個調(diào)用的地方都要寫重復(fù)的try catch 以及獲得和釋放 連接的代碼豈不是很無聊？那么，我們可以用一個服務(wù)類包裝他，這就體現(xiàn)了IOper 接口的用處了：
Java代碼
- public class EntityService {
- public Message add(IOper io) {
- try {
- Connection connect = Proxy.getConnect();
- connect.setAutoCommit(false);
- // 增加
- if (!io.add(connect)) {
- throw new Exception("增加操作失敗");
- }
- // 其他操作
- connect.commit();
- return new Message(true);
- } catch (Exception e) {
- Proxy.rollbackConnect();
- e.printStackTrace();
- return new Message(e);
- } finally {
- Proxy.closeConnect();
- }
- }
- public Message update(IOper io) {
- try {
- Connection connect = Proxy.getConnect();
- connect.setAutoCommit(false);
- // 修改
- if (!io.update(connect)) {
- throw new Exception("修改操作失敗");
- }
- // 其他操作
- connect.commit();
- return new Message(true);
- } catch (Exception e) {
- Proxy.rollbackConnect();
- e.printStackTrace();
- return new Message(e);
- } finally {
- Proxy.closeConnect();
- }
- }
- public Message delete(IOper io) {
- try {
- Connection connect = Proxy.getConnect();
- connect.setAutoCommit(false);
- // 刪除
- if (!io.delete(connect)) {
- throw new Exception("刪除操作失敗");
- }
- // 其他操作
- connect.commit();
- return new Message(true);
- } catch (Exception e) {
- Proxy.rollbackConnect();
- e.printStackTrace();
- return new Message(e);
- } finally {
- Proxy.closeConnect();
- }
- }
- public Message load(IOper io) {
- try {
- Connection connect = Proxy.getConnect();
- connect.setAutoCommit(false);
- // 載入
- if (!io.load(connect)) {
- throw new Exception("載入操作失敗");
- }
- // 其他操作
- connect.commit();
- return new Message(true);
- } catch (Exception e) {
- Proxy.rollbackConnect();
- e.printStackTrace();
- return new Message(e);
- } finally {
- Proxy.closeConnect();
- }
- }
- }
從EntityService 的代碼中看到，try catch 應(yīng)該總是出現(xiàn)在服務(wù)層，只有一個獨立的服務(wù)才有必要保證一個完整的事務(wù)。如果你要在CUD 操作后記錄業(yè)務(wù)日志，那么你可以寫在“其他操作”的位置。由于對外界信息的依賴，比如用戶信息，功能ID 等等，在實際應(yīng)用中需要更復(fù)雜的設(shè)計。至此，我們完成了對ORM 行為的模擬，在調(diào)用的地方，我們只需要：
Java代碼
- EntityService es = new EntityService();
- Message m = es.add(worker);
盡管方法內(nèi)部的代碼仍然是繁瑣的，但是我們由于把這些代碼的位置聚焦于較少的地方而降低了繁瑣程度，同時也獲得了良好的結(jié)構(gòu)。對數(shù)據(jù)庫的操作更為直觀是“手寫”代碼的優(yōu)點，當(dāng)然，我們還可以選擇ibatis ，不過結(jié)構(gòu)就不會是這樣的了。同時筆者認(rèn)為sql 代碼總是和程序內(nèi)部息息相關(guān)，配置在外部看起來并不一定方便吧。
對于數(shù)據(jù)庫遷移問題，hibernate 很大程度的解決了這個問題，不過企業(yè)開發(fā)中遷移數(shù)據(jù)的需求并不多，而且數(shù)據(jù)庫遷移不是使用某個工具或者規(guī)范（jdbc ，jdo ）就可以完全解決的，對于大型復(fù)雜應(yīng)用，遷移數(shù)據(jù)庫需要付出巨大的努力，所以實際上也沒有人這么做。
(V) 客戶端MVC
關(guān)于客戶端應(yīng)用的說明沒有內(nèi)部分段，因為Java EE 技術(shù)（暫不談javafx ）本身就和客戶端沒有太大關(guān)系，所以也不存在不足的問題，這里只是意圖糾正一些系統(tǒng)中不良的編碼習(xí)慣。
jsf 是Java EE UI 框架規(guī)范，前端控制器、事件模型和UI 組件是他的主要組成部分，但是實際開發(fā)中jsf 標(biāo)簽非常繁瑣，并且只有客戶端明確禁用腳本或者其他組件（flex-flash ，javafx 甚至silverlight ）時，jsf 才是最有價值的，糟糕（幸運）的是目前幾乎沒有客戶端瀏覽器不支持以上腳本或插件，所以jsf 的價值大大降低了。
jsp 是Java EE 視圖組件，也是jsf UI 框架的基礎(chǔ)之一，他實際上就是一個環(huán)境寬松的視圖模板，盡管這種寬松貌似不利于軟件分層，但是比起其他模板技術(shù)，他至少有一個優(yōu)點，就是非常象asp ，這使他更容易為開發(fā)者所接受。在web2.0 的時代，如果你的項目不打算用flex-flash 或者javafx ，那么jsp 就是你最佳的視圖載體，你可以把javacript 、css 、html 、xml 、json 還有java 代碼都放在這里，為了實現(xiàn)ajax 的交互邏輯，你可能要寫大段的javascript ，沒關(guān)系，jsp 都能承受，盡管，這些東西放在一起看上去就像是一個老鼠窩。
Ajax in action 的作者提出了客戶端MVC 的概念，不過別誤會，這并不是ext 或者flex 的開發(fā)模式，而只是一種觀念。html 是由dom 樹建立的視圖結(jié)構(gòu)，所以是M ，css 給html 結(jié)構(gòu)添加效果，所以是V ，javascript 控制顯示邏輯，所是C ，這里指的客戶端MVC 就是把這三種語言代碼分別建立單獨的文件，在html 頁面中引用外部的css 和js 。同樣拿員工信息錄入舉例，我們可以建立如下幾個文件：
worker_input.jsp
worker_inptu.js
style.css
可以看到，css 文件我們并沒有用功能方式命名，因為樣式表往往可以被整個系統(tǒng)共用，也就是說，我們只要記得不在html 里寫css ，js 代碼，并單獨建立js 文件就可以了。不同種類代碼分開建立文件是提高代碼可讀性的關(guān)鍵步驟，尤其是在客戶端程序愈發(fā)復(fù)雜的今天。worker_input.js 是這樣寫的：
Js代碼
- // 保存
- function save(){
- if(check()){
- AjaxUtil.sendForm(document.forms[0], "method=save", function () {
- if (this.result.succeed) {
- document.forms[0].reset();
- messageapp.printMessage(this.result.succeed);
- } else if (this.result.error) {
- messageapp.printMessage(this.result.error);
- }
- }, true);
- }
- }
這個文件只定義了一個save 方法，這個方法內(nèi)部發(fā)起了ajax 方式的異步請求，如果返回成功，則重置表單，并更新輸出信息到指定位置，反之則僅更新輸出信息。你會注意到，我們返回的JSON 對象起到了作用。
問題：如果我的jsp 代碼里出現(xiàn)了這樣的情況，算是違背客戶端MVC 的原則嗎？
Html代碼
- < tr>
- < td colspan="2">
- < input type="button" value="保 存" onclick="save();"/>
- < input type="reset" value="重 置" />
- < input type="button" value="返 回" onclick="window.history.go(-1);" />
- < /td>
- < /tr>
以上代碼片段中有簡短的 js 代碼和方法引用，這種情況，筆者認(rèn)為是可以的，項目開發(fā)沒必要追去絕對的完美，只要達(dá)到結(jié)構(gòu)清晰的目的就行了，我們要的是高質(zhì)量的產(chǎn)品，而不是高質(zhì)量的理論。
問題：如果我使用了類似 ror 的 JavaScriptHelper 那樣的腳本標(biāo)簽庫，生成的腳本與 html 代碼混在一起，這樣算不算違背客戶端 MVC 原則呢？很顯然，也不算，因為對于輸出前的 jsp 代碼模板，程序結(jié)構(gòu)是清晰的。
(F) 結(jié)構(gòu)和細(xì)節(jié)
關(guān)于MVC 各部分的介紹，再讓我們來看看整體結(jié)構(gòu)，假設(shè)我們是在一個eclipse 工程中，打開WebRoot 目錄，如果忽略META-INF 和WEB-INF 目錄的話，我們的示例目錄是這樣的：
module
404.jsp
500.jsp
index.htm
其中module 就是我們應(yīng)用所有的視圖，由于我們對于jsp 的使用方式，還包括所有的控制器。將應(yīng)用程序都放在一個目錄下是為了方便今后使用filter 對目錄進(jìn)行保護，或者進(jìn)行某些其他預(yù)處理。打開module 目錄，展現(xiàn)的結(jié)構(gòu)是這樣的：
- common
- worker
一個common 目錄，存放所有共用程序文件，一個worker 目錄存放關(guān)于員工這個實體的功能文件。實際上你的結(jié)構(gòu)也可能是sys/worker 或者center/sys/worker 等等，就要看實際的應(yīng)用需求了，總之，通過目錄劃分功能模塊，以正確的樹形結(jié)構(gòu)描述他是沒錯的。我們再來打開common 目錄：
- css
- img
- js
- import_page.def
前三個目錄分別存放的是常用文件，而最后一個是文件，這個文件將用這種方式添加到每個視圖jsp 頭，在< head>< /head> 間加入：
Jsp代碼
- < %@ include file=”../common/import_page.def”%>
這里使用了相對路徑，增加這個文件是為了方便的引用其他css 和js 庫文件。使用這種方式可以避免在部署的階段因合并js 或進(jìn)行css 、js 庫文件的版本變更而帶來的麻煩。
再來看看java src 的目錄結(jié)構(gòu)：
- webappdeom
- common
- worker
網(wǎng)頁題目：無框架架構(gòu)模型探討：簡化的JavaEE開發(fā)
新聞來源：http://fisionsoft.com.cn/article/dhhgpdh.html
