對《jsp作?BS前台主流方案是方向錯誤 》的歸納性解釋

《選擇jsp而不是servlet作?BS前台主流方案是JAVA的戰略性方向錯誤 》已經被不少網友轉載，並有許多反饋意見。現主要就負面的反饋意見的基本面進行一次歸納性的回答。

《選擇jsp而不是servlet作?BS前台主流方案是JAVA的戰略性方向錯誤 》一文是經驗角度對jsp選擇方向的一種質疑；其不受"公論"（公論對中國人的思維影響很大）的逆向思維方式本身就會引起爭論，本是意料中的。現把部分爭論回答歸納起來，學習、實踐、爭論、歸納、再實踐，這是取得提高和突破的途徑。

首先，JSP是一種WEB界面處理方式（不是語言），所以是否適用MCV模式實際在存在著很大的爭議。所以MCV模式作?JSP/SERVLET的 選擇依據是不合適的。不過，JSP/SERVLET的表達層的應用方式，是沒有疑問的，盡可能將業務邏輯層分離出去，符合項目需求控制和成本控制的原則， 最終將提高項目質量並降低維護成本。無論是那一種方案，將應用業務邏輯包裝起來，成?與其他模塊/層盡可能低耦合的類，也是一種必然的選擇，也是面向對象 的方式的體現；面向對象方式主要體現?繼承/接口，如果否認它的積極意義，也就沒有討論的余地了。

OOP誰都會接受的，但這?關鍵焦點在于，對象是什?？在不同的環境，對象有完全不同的含義，脫離這點，OOP其實成了一個過分泛濫的無用的名詞。 在VB中它通常表示界面中的一個視窗組件；而在C++中，通常是處理的一組功能；在JAVA中的業務邏輯中，對象一般是有獨立意義的一種客觀事物，而當 JAVA用于表達層時，無論是JSP/還是swing.awt，它都象VB一樣表達一種view圖結構。到底表達什?，什?可以抽象，什?應該抽象，很大 程度取決于開發者的經驗習慣。

JSP中適用那種類型，首先要回憶JSP針對的開發模式/假想是什?，也就是JSP這種技術?品出現時的分析用例是什?。文中其實已經提到了最根本 的論點和解釋（居然有網友沒有讀出來），JSP用例是抄ASP的，也就是"希望非程序人員可以直接生成動態內容"的JSP，這是SUN選擇向JSP進化的 最根本的理由。文中最大的論據也在于：事實表明非程序人員寫不了JSP；所以JSP側重點本身就錯了，它應該選擇方便程序員的方向!

再回想一下各人接手的項目是什?形式的。或者是從個人開始，按客戶要求（甚至自已就是客戶？）直接開發系統；開發一個版反饋給客戶再修改第二版？還 是接手一批原型，一般是HTML，然後從這?著手抽象可以抽象的東西，包裝可以包裝的東西？即使是第一種情況，開發者包打天下，最經常的方式是什?呢？應 該是萬般抄開始，從網上找相近的網頁，變成HTML後修改。可見，可以把WEB的開發看作是從HTML開始的。問題的差別就在于是如何從HTML開始的。

如果認?是從HTML直接開始，從中通過插入各種生成值，也就是SUN最早假設的方式；最終生成簡單的網頁，當功能不太OK 時再一頁頁延伸，那?JSP的確是合適的選擇。順便說一句，如果生成的是邏輯功能簡單而頁面表達複雜的HTML，（這是中國式網站的最典型情況），JSP 的優越性是非常明顯的。不過反過來，這樣的缺點也就在于隨著項目的開展、龐大、複雜化，開發者和維護者最終都會陷入"網頁陷阱"，也就是頁面變程序缺乏邏輯的聯系，變得難以維護了，這其實也是?什?要用動態網頁代替HTML的原因。

更通常的做法是在HTML上再處理，抽取出各個特征代碼，一一包裝起來成?可重用的組件，（注意和業務邏輯組件的區別），另一方面，組件中的 HTML代碼?了修改方便，要求修改後是無需編譯的。從這個要求出發，派生出了XML/XSL/XSLT一整個體系，也派生出了TILES，SLIDE， struts包括它的validator,等等。無論是那一種，HTML必須整理再分解才有可能達到重用和降低維護成本的目的。對于功能/內容/服務驅動 的網站，網頁一般簡潔並功能模塊重用性高，這種操作方式尤其顯得高效而簡潔，網頁本身就可以直接用UML/USECASE的方式預先設計。這就是《選擇 jsp而不是servlet作?BS前台主流方案是JAVA的戰略性方向錯誤 》中假設的項目類型，也就是這時侯，對象的繼承對于表達層才有現實的意義。

事實上，JSP也是基本支持上面的網頁分解、抽象、重用，最經常是使用include方式；在taglib和struts:logic中，還可以根 據上下文變量條件決定include，所以也基本上達到了類似的目的。《選擇jsp而不是servlet作?BS前台主流方案是JAVA的戰略性方向錯 誤》一文爭論的是，是JSP不能處理重用頂級模板，限制了這種表達層對象抽象重用的水平。如果選用servlet?主要方向，同樣的投入，要達到方便程序 員直接修改界面代碼，同時也便于（選擇）各個方向層次的對象應用，就沒有JSP那樣的障礙的。SUN在開始JSP時是一個無負擔的開發者，完全可以這樣 做，但卻選擇了與ASP雷同的用例方案，沒有利用自已最大威力的對象語言，把JAVA降格成腳本（javalet），最終不得不通過開發標簽 /javabean來彌補原來的不足，不但加大了學習者的負擔（就以Tag而論，能熟練使用的jsp程序員有幾何？），也減少了自已的市場份額和市場成功 的機會。這就是對《選擇jsp而不是servlet作?BS前台主流方案是JAVA的戰略性方向錯誤 》批評SUN是笨蛋的原因。

無論如何，IT/軟件行業，是一個支持獨立思考，支持創造性思維的行業，可以懷疑一切權威，在實踐中體驗並用實踐來證明，是軟件行業技術進步的基 礎，也是IT行業存在的基礎。這不是一個子日詩雲，權威（老師）定論的領域，如果否認這一點，象一些人表現的那樣對權威的奴性崇拜，也就沒有什?再討論的 必要性了。

http://blog.csdn.net/zwwwxy/archive/2005/04/02/334958.aspx

http://zwwwxy.blogchina.com/1081807.html

http://blog.csdn.net/zwwwxy/archive/2005/03/30/333818.aspx

http://zwwwxy.blogchina.com/blog/article_81038.521777.html

http://zwwwxy.blogchina.com/443048.html