在J2EE領域來說，SSH/SSI是好東西，是大師們嘔心瀝血的結晶。但，他也是壞東西。

好的一面，相信不用多說，大量的設計模式運用，極大的降低程序員入門門檻，規范企業應用開發，提高生產效率等等。無論從企業成本抑或個人技術發展方面，都堪稱精華之作。

現在，我們討論它壞的一面：

1.降低程序員入門門檻

　　你只需要一本《xx天學會xx》，就可以參加工作，贏取其他行業羨慕的薪水。但，這真的好嗎？！我們不講程序是算法和數據結構的結合，不講高大上的理論和技術，我們都是平凡人。從急需就業的角度講，能讓你快速學會一門技術，這是很好的。但是，當很多平凡人嘗到了這個急功近利的甜頭后，就覺得技術就是這樣，我什么時候用到了再臨時抱下佛腳，于是不思進取，混吃等死。越來越多的企業應用開發人員進入了這種狀態中。有的人知道這是不對的，可是看到別人是這樣，自己隨大流，也不去改變。

2.規范企業應用開發

　　從企業生產角度看，能夠把本來無法規范的事情，形成規范化的流程化的生產過程，這是非常好的事情，可以大大降低生產成本，提高產品質量。但是，流程的副產物就是僵化！

　　前面說到，由于入門門檻降低，魚龍混雜，人員水平參差不齊。對于這種規范，有的人理解他是規范，是參照物，有的人理解他是規定，是必須遵守的準則，再加上不思進取，知其然而不知其所以然，導致這種僵化現象更加嚴重。

3.大量的設計模式運用

　　部分開發人員看到框架這么用設計模式，于是看見什么都像釘子，這個與本篇主題關聯不大，這里不多討論。

道理講完，我們來看具體的例子。

相信很多人在開發SSH/SSI應用時，都要寫jsp,action,service,dao這幾個典型模塊。那么，我為什么開發一個功能需要寫這些模塊，我為什么不可以用其他的方式來實現？

有人說，因為這是遵循MVC模式，是針對業務的分層模型，更便于開發維護，及與其他開發人員交流。

那么，我們就從MVC入手，看看為什么要這么做開發。

V：View視圖層，也就是直接和用戶交互的那一層，是數據展示層

C: Controller調度層，指將view層的請求轉發給服務層，組合調度服務層實現view層的請求，并將服務層的數據返回view層

M: Model數據模型,指服務層+數據層，也就是常說的Service+Dao，主要用來實現業務邏輯，并返回業務數據

上面的理論相信每一個J2EE的開發人員都有看過相關介紹。對于View層，我們不多討論，無論使用哪種View技術，它的目的比較單一，相對比較容易理解。

這里主要說C和M。

常規的做法是，新建Action，新建Service接口，新建Dao接口，新建ServiceImpl實現Service接口，新建DaoImpl實現Dao接口。

這里就回到主題了，為什么一定要這樣建這么多類和接口？

很多初級開發人員不管三七二十一，上級這么要求，就這么寫，不懂變通，久而久之，就認為web就應該是這樣的.....

或者，混淆C和M的職責，造成業務邏輯混亂，代碼大量冗余。

那么正確的做法是什么？

一、職責單一，專注

小到一個方法，一個類，大到一個模塊，再大到一個系統，它所做的事情應該是單一的，它只應該專注一件事，一個領域。

Controller調度器，既然稱為調度器，就不應該存在復雜的業務邏輯，它的職責應該是單一的，就是負責吧下層的服務模塊組合排列，實現view層的數據請求。

Service服務層，既然稱為服務層，就應該專注于服務，實現所有的業務邏輯，調用并組合Dao層查詢方法，不應該存在調度和直接DB請求。

Dao,Database access Object,數據庫訪問層，專注數據庫訪問，不應該存在業務邏輯。

二、模塊化

前面說到Controller負責調度，那假如我把所有的業務都寫到一個service方法里面，action就調了一個方法，別的什么事情也沒做，那這個調度是不是就沒用的？（service也一樣，如果沒有業務邏輯，單純調用Dao方法）。

需求就像一個奇形怪狀的建筑物，你有兩個選擇：

1.直接造一個這樣形狀的建筑物，滿足需求，下一次在直接造。

2.切分，將這個奇形怪狀的建筑物切分成規則形狀的積木，然后拼接粘合起來。下一次繼續切分，慢慢的你手里的規則積木越來越多，你的代碼也會越來越好寫，每個新需求，你只要利用現有積木加上一點膠水粘起來即可。這時候action,service的真正功能才能體現出來。

這里說的積木就是模塊，這個模塊可以是一個方法，一個類，一個封裝完整的功能。

相信都能看出來那種方法是好的，但是為什么大多數人都要采用第一種方法來寫代碼呢？

三、大而化之

在職責和模塊討論清楚后，我們來考慮，view/action/service/dao到底是什么，可否換一種寫法，當我們在分層的角度，在來看他們，其實他們只是一種層次的劃分，上層依賴下層，下層為上層提供服務，框架定義了我們要這樣分N層來寫。那我也完全可以自己定義分四層，五層...只要業務需要,于是這就形成了一種屬于你自己的編程思想。

上面三步需要一步步走扎實，當然，剛開始肯定是比較困難的，也許比你平常寫代碼還要困難，也更慢，這時候你需要一種品質：處女座(追求極致)！ :)

我們都知道java世界的工具框架很多，對于工程化開發來說，專注業務，不用造輪子，不錯！但是對于開發人員自己來說，就很容易造成思維僵化，入門容易，基礎差，提升困難！

這也應該是C程序員轉java容易，java程序員轉C困難的一部分原因吧！畢竟很多老C程序員是自己維護自己的工具庫，而這工具庫是自己一個個碼出來的。寶劍鋒從磨礪出，外部環境的優沃常常造成基礎的不牢固。

常常說懶是一個程序員的優秀品質，因為計算機本身就是懶的產物。但是，在夯實基礎時，必須苦功夫，笨功夫，追求極致，凡事多問多想幾個為什么，你才能有懶的資本。

任何事情都有兩面，過猶不及，中庸不等于平庸！