在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程序員是自己維護自己的工具庫，而這工具庫是自己一個個碼出來的。寶劍鋒從磨砺出，外部環境的優沃常常造成基礎的不牢固。
常常說懶是一個程序員的優秀品質，因為計算機本身就是懶的產物。但是，在夯實基礎時，必須苦功夫，笨功夫，追求極致，凡事多問多想幾個為什麼，你才能有懶的資本。
任何事情都有兩面，過猶不及，中庸不等於平庸！
