我爲何要選擇SSH框架

 　　選擇框架，並非要簡化開發過程，雖然有時確實提升了開發速度。但這種提高可能是因爲框架的基本結構在全部的應用裏都差很少，節省了設計的時間，能夠直接開始配置系統大環境。同時框架的管理層面已是很是成熟的，不須要咱們再作過多的考慮。

 　　其實框架的應用和流行和MVC設計理念息息相關，而MVC自己不是爲了簡化什麼，而是爲了規範什麼。若是你對MVC都不承認的話，那咱們就不必再談論框架了。

 　　有些人說，不少方法都比使用框架要靈活方便簡捷不少。可是，這種開發是否是放棄了對系統的設計理念，回到了MVC以前，僅僅爲了實現而編程。在沒有MVC的日子裏，系統的維護、擴展、安全以及穩定都是隨時能夠威脅系統生命的大問題。而如今，分層的設計理念大大提升了開發的效率，而且規避了很多的bug。我認爲MVC和框架的出現是程序開發領域的一個進步。儘管如今尚未一個完美的框架，但框架的出現打開了編程的新紀元，咱們應該積極地學習、掌握它。

 　　不少人一說起框架就是SSH，其實這只是一種比較流行的組合而已，但你能夠單用其中任何一個，這也是框架的使用（我以爲Spring是最有用的）。使用框架不過是對MVC一個規範的體現，經過使用框架，你的工程天然而然就分離各層，達到了高效先進的設計理念。

 　　首先，開發效率：軟件工程是個特殊的行業，不一樣於傳統的工業，例如電器、建築及汽車等行業。這些行業的產品一旦開發出來，交付用戶使用後將不多須要後續的維護。但軟件行業不一樣，軟件產品的後期運行維護是個巨大的工程。若是不使用框架分層，將整個站點的業務邏輯和表現邏輯都混雜頁面裏，從而致使頁面的可讀性至關差，可維護性很是低。即便須要簡單改變頁面的按鈕，也不得不打開頁面文件，冒着破壞系統的風險。但採用嚴格分層框架，則可徹底避免這個問題。對錶現層的修改即便發生錯誤，也絕對不會將錯誤擴展到業務邏輯層，更不會影響持久層。所以，採用框架，即便前期的開發效率稍微低一點，但也是值得的。

 　　其次，需求的變動：幾乎不多有軟件產品的需求從一開始就徹底是固定的。客戶對軟件需求，是隨着軟件開發過程的深刻，不斷明晰起來的。所以，經常遇到軟件開發到必定程度時，因爲客戶對軟件需求發生了變化，使得軟件的實現不得不隨之改變。當軟件實現須要改變時，是否能夠儘量減小修改、少改變軟件的實現，從而知足需求的變動？答案是確定的，採用優秀的解耦架構。在優秀的分層架構裏，控制層依賴於業務邏輯層，但毫不與任何具體的業務邏輯組件耦合，只與接口耦合；一樣，業務邏輯層依賴於DAO層，也不會與任何具體的DAO組件耦合，而是面向接口編程。採用這種方式的軟件實現，即便軟件的部分發生改變，其餘部分也儘量不要改變。

 　　對於技術的更新，系統重構：軟件行業的技術更新很快，一旦環境變化，不得不更換技術時，如何保證系統的改變最小呢？答案確定是選擇優秀的框架。