SSH：Struts（表示層）+Spring（業務層）+Hibernate（持久層）
在項目開發的過程中，有時把整個項目分爲三層架構，其中包括：
1、表示層(UI)、
2、業務邏輯層(BLL)
3、數據訪問層(DAL)。
三層的作用分別如下：
表示層：爲用戶提供交互操作界面，這一點不論是對於Web還是WinForm都是如此，就是用戶界面操作。
業務邏輯層：負責關鍵業務的處理和數據的傳遞。複雜的邏輯判斷和涉及到數據庫的數據驗證都需要在此做出處理。根據傳入的值返回用戶想得到的值，或者處理相關的邏輯。
數據訪問層：負責數據庫數據的訪問。主要爲業務邏輯層提供數據，根據傳入的值來操作數據庫，增、刪、改、查。
三層的理解
表示層的內容就是來和用戶打交道，通俗講就是展現給用戶的界面，用戶的要求都體現在界面上。
業務邏輯層的功能主要是實現一些具體問題的操作，它是表示層和數據訪問層之間溝通的橋樑，主要負責數據的傳遞和處理。
數據訪問層的功能就是對數據庫中表的內容的增刪改查。
三層的實現將我們的系統的實現過程分門別類，每一層自己做自己的事，互不影響，當我需要其他層的內容時，再去調用。當需要修改時只需改動本層的內容，不會影響到整個系統的代碼。
就是傳說中的解耦。讓那個每一層只關心自己內部的事情，它只知道下層的存在，不知道上層的存在。達到局部改變而不影響全局的目的！
優點
1、開發人員可以只關注整個結構中的其中某一層；
2、可以很容易的用新的實現來替換原有層次的實現；
3、可以降低層與層之間的依賴；
4、有利於標準化；
5、利於各層邏輯的複用。
缺點
1、降低了系統的性能。如果不採用分層式結構，很多業務可以直接造訪數據庫，以此獲取相應的數據，如今卻必須通過中間層來完成。
2、有時會導致級聯的修改。這種修改尤其體現在自上而下的方向。如果在表示層中需要增加一個功能，爲保證其設計符合分層式結構，可能需要在相應的業務邏輯層和數據訪問層中都增加相應的代碼。
3、增加了開發成本。
三層與MVC的區別
1、MVC主要用於表現層，3層主要用於體系架構，3層一般是表現層、中間層、數據層，其中表現層又可以分成M、V、C，(ModelView Controller)模型－視圖－控制器
2、MVC是表現層的架構，MVC的Model實際上是ViewModel，即供View進行展示的數據。ViewModel不包含業務邏輯，也不包含數據讀取。
Struts：Struts是一個表示層框架，主要作用是界面展示，接收請求，分發請求。
在MVC框架中，Struts屬於VC層次，負責界面表現，負責MVC關係的分發。
（View：沿用JSP，HTTP，Form，Tag，Resourse ；Controller：ActionServlet，struts-config.xml，Action）
Hibernate：Hibernate是一個持久層框架，它只負責與關係數據庫的操作。
Spring：Spring是一個業務層框架，是一個整合的框架，能夠很好地黏合表示層與持久層。
我們知道，傳統的Java Web應用程序是採用JSP+Servlet+Javabean來實現的，這種模式實現了最基本的MVC分層，
使的程序結構分爲幾層，有負責前臺展示的 JSP、負責流程邏輯控制的Servlet以及負責數據封裝的Javabean。
但是這種結構仍然存在問題：
如JSP頁面中需要使用符號嵌入很多的 Java代碼，造成頁面結構混亂，
Servlet和Javabean負責了大量的跳轉和運算工作，耦合緊密，程序複用度低等等。
Struts 爲了解決這些問題，出現了Struts框架，
它是一個完美的MVC實現，它有一箇中央控制類(一個 Servlet)，針對不同的業務，
我們需要一個Action類負責頁面跳轉和後臺邏輯運算，一個或幾個JSP頁面負責數據的輸入和輸出顯示，
還有一個 Form類負責傳遞Action和JSP中間的數據。JSP中可以使用Struts框架提供的一組標籤，就像使用HTML標籤一樣簡單，但是可以完成非常複雜的邏輯。
從此JSP頁面中不需要出現一行包圍的Java代碼了。 可是所有的運算邏輯都放在Struts的Action裏將使得 Action類複用度低和邏輯混亂，
所以通常人們會把整個Web應用程序分爲三層，Struts負責顯示層，它調用業務層完成運算邏輯，業務層再調用持久層完成數據庫的讀寫。
使用JDBC連接來讀寫數據庫，我們最常見的就是打開數據庫連接、使用複雜的SQL語句進行讀寫、關閉連接，獲得的數據又需要轉換或封裝後往外傳，這是一個非常煩瑣的過程。
Hibernate 這時出現了 Hibernate框架，它需要你創建一系列的持久化類，
每個類的屬性都可以簡單的看做和一張數據庫表的屬性一一對應，當然也可以實現關係數據庫的各種表件關聯的對應。
當我們需要相關操作是，不用再關注數據庫表。我們不用再去一行行的查詢數據庫，只需要持久化類就可以完成增刪改查的功能。
使我們的軟件開發真正面向對象，而不是面向混亂的代碼。
我的感受是，使用Hibernate比JDBC方式減少了80%的編程量。
現在我們有三個層了，可是每層之間的調用是怎樣的呢?比如顯示層的Struts需要調用一個業務類，
就需要new一個業務類出來，然後使用;業務層需要調用持久層的類，也需要new一個持久層類出來用。
通過這種new的方式互相調用就是軟件開發中最糟糕設計的體現。
簡單的說，就是調用者依賴被調用者，它們之間形成了強耦合，
如果我想在其他地方複用某個類，則這個類依賴的其他類也需要包含。
程序就變得很混亂，每個類互相依賴互相調用，複用度極低。
如果一個類做了修改，則依賴它的很多類都會受到牽連。 爲此，出現Spring框架。
Spring Spring的作用就是完全解耦類之間的依賴關係，
一個類如果要依賴什麼，那就是一個接口。
至於如何實現這個接口，這都不重要了。
只要拿到一個實現了這個接口的類，就可以輕鬆的通過xml配置文件把實現類注射到調用接口的那個類裏。
所有類之間的這種依賴關係就完全通過配置文件的方式替代了。
所以 Spring框架最核心的就是所謂的依賴注射和控制反轉。
現在的結構是，Struts負責顯示層，Hibernate負責持久層，
Spring負責中間的業務層，這個結構是目前國內最流行的Java Web應用程序架構了。
另外，由於Spring使用的依賴注射以及AOP(面向方面編程)，所以它的這種內部模式非常優秀，
以至於Spring自己也實現了一個使用依賴注射的MVC框架，叫做Spring MVC，同時爲了很好的處理事物，Spring集成了Hibernate，
使事物管理從Hibernate的持久層提升到了業務層，使用更加方便和強大。
Struts框架是2000年就開始起步了，到目前已經發展了5年，
技術相當成熟，目前全球Java開發中Struts框架是顯示層技術中當之無愧的王者。
它擁有大量的用戶羣和很好的開發團隊。
這也是國內大部分Java軟件公司對新進員工的基本要求。
其他 Java這個名詞似乎註定和開源緊密聯繫在一起了，在Java界，每天都有大量的開源技術出現，
由於是開放源代碼的，技術中存在的問題和不足很快就會被人發現，
開源軟件提供者會很快的修正或擴展這些技術，因此版本更新很快，幾個星期或者幾天就有一個新版本出來。
當我們在技術線路中選擇了Java，也就選擇了你必須持續學習，經常關注最新的技術，瞭解它們，
看是否適合你的需要，然後學習使用它們。
在用ssh 開發web應用時，需要對生成的 各個類文件進行組織，下面就對一個可行的 目錄方案進行介紹：
譬如應用中有一個用戶管理模塊，則在公共包下建立一個user包，如該公共包可以爲com.simon.oa，
在user包下包括如下子包
1、controler包
該包放置各種struts的 action。
2、dao包
該包放置各類dao（data access object），也就是放置對數據庫訪問的 實現類，在用myeclipse中的 “Hibernate Reverse Engineering”進行反向操作時在某一個目錄中就會生成對應某個表的 DAO，生成後可將該DAO拖到dao包中。在某些應用中將DAO作爲接口，在該接口中包括所有對數據庫的 操作方法，然後在dao包建立一個hibernate包，在hibernate包中放置對DAO接口的 實現，譬如：UserDAO接口有一個實現類爲UserDaoImpl，將該類放置到hibernate包中，實際的 開發傾向於後一種方式，因爲對這個DAO接口可以實現spring的 IoC操作。(不知道myeclipse對此是怎麼考慮的 ，這個問題讓我糾纏了很久，誤將DAO理解成一個能夠進行實際操作的 類，而不是一個接口，以後開發要注意 )
3、model包
該包中放置hibernate反向工程生成的 bean和該bean對應的 .hbm.xml文件。
4、service包
該包放置業務操作類，譬如用戶服務類，一般情況將該用戶操作類提取一個接口，然後在service包下生成一個impl包，在impl包中才放置用戶操作接口的實現類。該用戶接口實現類中調用DAO接口對數據庫進行操作，而調用該實現類的 方法在struts的 action中。
5、vo包（value object）
vo包中的 中包括struts中使用的 POJO及actionform等信息。
VO: Value Object
DTO: Data Transfer Object
個人理解VO和DTO是類似的 東西，原則上VO和DTO只有Public Fields，主要用於進程之間數據傳遞的 問題，VO和DTO不會傳遞到表示層，在業務層就會被吸收。但看到很多人在建立VO和DTO時，也含有Setter,Getter屬性和一些其它的 輔助方法，這也無可厚非，我自己也不能確定這對不對。