最近搞了一下SSH，首先是因爲SSH還不熟，只是大一暑假時搭建過一次，後來就一直沒有搞，暑假那次還是在視頻的指導，
和其他人的指點下完成的。原理和思想也不清楚。畢竟當時J2EE剛入門，再加上我們中心的一貫作風，“不求甚解，實現至尚”的原
則。所以一說起SSH，自己就非常心虛。畢竟自己不懂原理，只會搭個殼，也沒搞過項目，沒有實踐的積累。終於在手頭的助學網後臺
功能全部over而頁面一直沒有音訊的情況下，抽出了時間把SSH着實鞏固了一番。咳~~~還覺得基礎還是不夠好。一個框架都搞不透。
經過連續幾天斷斷續續的吐血下，終於算是征服了SSH。
******************************************************************
切入正題，SSH就是struts1.0與Hibernate由spring解耦合。
SSH分三層，web層（struts），業務邏輯層，數據庫操作層（Hibernate）。SSH是J2EE中應用最爲廣泛的系統級開發框架。
因爲它的易於維護和拓展，使得SSH得到廣泛的應用。
SSH的精髓在於spring的管理。
******************************************************************
常見的SSH層一般分爲7層：
dao層（數據庫接口），daoimpl層（數據庫操作實現類），vo層（POJO類，數據庫實體類），service層（業務邏輯層接口），
serviceimpl層（業務邏輯實現層），action層（web邏輯處理層），form（表單處理層）。
struts開發項目由來已久，可以說是實現MVC的最早的完善框架。但是技術一直在發展與進步，以至於現在漸漸的已經被更實用的
框架取代，例如struts2（webwook+struts的結合），JSF......之類，這些框架會更好使，更加合理，開發會更easy。但是如果說發展的
成熟度，其實這些新興框架，也足夠完善。起碼struts2已經可以很好的開發。從而也就有了我之前的隨筆《struts2+spring+Hibernate搭建全解》
。其實前段用哪個框架也不是固定的。
Hibernate是數據庫持久化的框架，是我們從以往的操作數據庫轉變爲操作對象。更利於面向對象編程。而且也對數據庫操作進行了封裝。
優化了sql語句，異常拋出，開閉連接等等。可以說是非常完善的底層框架。spring對Hibernate注入的操作和方法。也更加方便了操作。但是我並
不主張，讓spring過多的注入Hibernate，因爲spring的誕生就是解耦的。使web層，與數據庫底層操作分離。這樣把業務邏輯分離出來。便於擴展
新功能或刪除不用的功能，或着移植代碼。是在MVC模式把美工（UI設計）和後臺編程分離來後的又一大革新。使程序員面向接口編程。把後臺的
開發也完美的分離。對於小型的項目來說也許並不意味着什麼。但是對於中大型項目來說，節省了大把的開發成本。
spring就是SSH的畫龍點睛之處。spring的精華在於反射機制。偶不得不讚嘆
spring的兩個核心AOP（面向切面編程），IOC（依賴注入）十分的帥。這兩個思想，體現在spring的XML配置文件之中。 其中的依賴注入
是由Bean實現，從而實現面向切面編程，事務的管理。ACEGI（security）（權限驗證框架，有待偶的進一步研究）框架中體現就明顯。
******************************************************************
廢話也不想多說，直接說SSH思想和特點：
1.除了實例化POJO對象需要new對象以外實現impl不再需要new對象，一切都是getBean讀取配置文件spring配置文件。
2. 解耦web層與數據庫操作層。
3. 利用反射動態獲取所有類信息。
4. 對數據庫的操作對象化，除了取出單獨字段和查詢外，儘量使用數據庫實例化對象，儘量不使用HQL語句。
******************************************************************
我在剛開始SSH搭建的過程中總是遇到空指針。這就是由於我的思想還停留在struts+Hibernate層面，沒有理解SSH的思想。
這樣的話，我的這路實現操作與spring根本不同路，而Hibernate又是通過spring配置的。所以當然數據庫操作會報空指針的錯。
這個困擾我很久。然後就是什麼樣的分層纔是最帥的最合理的。
最終借鑑網上的一些思想和師兄的開發心得，我終於有了自己的實現分層思路。
******************************************************************
最初是打算一個DAO包括所有數據庫操作接口。一共20個接口：這套接口是非常成熟且實用的。包括：
增刪改查，動態查詢，高級搜索，分頁實現，動態分頁。 這是傳說中的BaseDao（當然你也可以叫別的名）。
然後一個BaseDaoImpl實現類。接着是業務邏輯層，和web層。除了這個基類Dao外不再有其他的數據庫操作類。
這樣業務邏輯層就變得臃腫。其中既有HQL，又有對象的實例化。但是我的想法是本着分離兩層，以後功能擴展修改
直接通過修改業務邏輯層一個層和web層。這樣就可以少維護一個層。但是後來師兄的心得使我改變了想法。
******************************************************************
師兄的項目是除了BaseDao接口外又新建了其他的數據庫操作接口。然後全部實例化操作。讓這些子接口繼承BaseDao接口，
，但是這樣就和我一開始的想法有點衝突。但是實事證明，這樣有好處。就是HQL，對象實例化都在DaoImpl裏，業務層專注實現
業務，根本不考慮底層操作。也沒有亂七八糟的HQL語句。如果修改業務，那麼DaoImpl也不用動。畢竟這些方法也不會佔幾百MB
代碼的項目多大地兒。留着唄，說不好以後有用呢。感覺這個方法就是我假期做東西的思路。
******************************************************************
最終我決定使用一個折中的方案，一個BaseDao，多個DaoImpl實現類。因爲Dao子接口基本和service層接口一致，所以如果
再寫一遍，總覺得是多餘。所以就不寫了，這套DaoImpl注入BaseDao的實現類方法，並且自己也繼承HibernateDaoSupport，
以方便使用泛型或者更靈活的操作數據庫對象。一個BaseAction封裝並重用getBean等spring與struts的action整合的類。
一個BaseService接口當然也不是必須的，負責業務實現中的對象創建與獲取，一個BaseServiceImpl也不是必須的，實例化BaseService
接口。
******************************************************************