Struts 模型組件
模型代表應用的業務數據和邏輯。Struts框架并沒有為設計和創建模型組件提供現成的框架。不過，Struts允許使用其他模型框架來處理應用的業務領域，如EJB(Enterprise JavaBean)和JDO(Java Data Object)，以及常規的JavaBean和ORM(Object-Relation Mapping)。
1 模型在MVC中的地位
模型是應用中最重要的一部分，它包含了業務實體和業務規則，負責訪問和更新持久化數據。應該把所有的模型組件放在系統中的同一個位置，這有利于維護數據的完整性，減少數據冗余，提高可重用性。
模型應該和視圖以及控制器之間保持獨立。在分層的的框架結構中，位于上層的視圖和控制器依賴于下層模型的實現，而上層模型不應該依賴于上層的視圖和控制器的實現。Struts應用的各個層次之間的依賴關系：
從上到下，依賴關系加強；從下到上，依賴關系減弱。
如果在模型組件中通過Java的import語句引入了視圖和控制器組件，這就違反了以上原則。下層組件訪問上層組件會使應用的維護、重用和擴展變得困難。
2 模型的概念和類型。
在科學和工程技術領域，模型是一個很有用途的概念，它可以用來模擬一個真實的系統。建立模型最主要的目的是幫助理解、描述或模擬真實世界中目標系統的運轉機制。
在軟件開發領域，模型用來表示真實世界的實體。在軟件開發的不同階段，需要為目標系統創建不同類型的模型。在分析階段，需要創建概念模型。在設計階段，需要創建設計模型。可以采用面向對象建模語言UML來描述模型。
2.1 概念模型
在建立模型之前，首先要對問題域進行詳細的分析，確定用例，接下來就可以根據用例來創建概念模型。概念模型用來模擬問題域中的真實實體。概念模型描述了每個實體的概念和屬性，以及實體之間的關系。但在這個階段并不描述實體的行為。
創建概念模型的目的是幫助更好地理解問題域，識別系統中的實體，這些實體在設計階段很有可能變成類。
概念模型清楚地顯示了問題域中的實體。不管是技術人員還是非技術人員都能看得懂概念模型，他們可以很容易地提出概念模型中存在的問題，幫助系統分析人員及早對模型進行修改。在軟件設計與開發周期中，模型的變更需求提出得越晚，所耗費的開發成本就越大。
2.2 設計模型
概念模型是在軟件分析階段創建的，它幫助開發人員對應的需求獲得清晰精確的理解。在軟件設計階段，需要在概念模型的基礎上創建設計模型。可以用UML類框圖，活動圖以及狀態圖來描述設計模型。
根據UML語言，類直接存在四種關系。
1
關聯(Association)
關聯指的是類之間的引用關系。
2 依賴(Dependency)
依賴指的是類之間的訪問關系。
3 累積(Aggregation)
累積指的是整體與個體之間的關系，可以把累積看作一種強關聯關系。
4 一般化(Generalization)
一般化指的是類之間的繼承元素。
3 業務對象(BO)
業務對象，即Business Object(BO)，是對真實世界的實體的軟件抽象。它可以代表業務領域中的人、地點、事物或概念。
業務對象包括狀態和行為。
判斷一個類是否可以成為業務對象的一個重要標準，是看這個類是否同時擁有狀態和行為。
3.1 業務對象的特征和類型
如果一個類可以作為業務對象，它應具有以下特征：
·
包含狀態和行為
·
代表業務領域的人、地點、事物或概念
·
可以重用
業務對象可分為三種類型：
·
實體業務對象
·
過程業務對象
·
事件業務對象
實體業務對象要算是最為人們所熟悉的。實體對象可以代表人、地點、事物或概念。通常，可以把業務領域中的名詞，例如客戶、訂單、商品等作為實體業務對象。在J2EE應用中，這些名詞可以作為實體Bean。對于更普通的Web應用，這些名詞可以作為包含狀態和行為的JavaBean。
過程業務對象代表應用種的業務過程或流程，它們通常依賴于實體業務對象。可以把業務領域中的動詞。例如客戶發出訂單、登入應用等作為過程業務對象。在J2EE應用中，它們通常作為會話Bean或者消息驅動Bean。在非J2EE應用中，他們可作為常規的JavaBean，具有管理和控制應用的行為。過程業務對象也可以擁有狀態，例如在J2EE應用中，會話Bean可分為有狀態和無狀態兩種。
事件業務對象代表應用中的一些時間（如異常、警告或超時）。這些時間通常由系統中的某種行為處罰。例如，在Java Swing應用中，當客戶按下一個按鈕，就會有一個事件業務對象產生，以便通知框架調用相關的時間處理器來處理事件。
3.2
業務對象的重要性
在
應用中使用業務對象有許多好處，最重要的一點就是業務對象提供了通用的術語和概念，不管是技術人員還是非技術人員都可以共享并理解他們。它們可以直觀地代
表真實世界中的概念，開發小組的所有成員都能理解他們。如果正對同一個業務領域需要開發出多個應用，那么這些應用可以共享這些業務對象。業務對象的可重用
特性可以提高應用開發速度。減少冗余。
此外，業務對象可以隱藏實現細節，對外只保露接口。例如，如果業務對象的某個方法需要傳入java.util.ArrayList類型的參數，那么應該把參數定義為java.util.List接口類型。這樣，假定這個方法的實現發生改變，用LinkedList取代ArrayList來實現原有的功能，這種概念不會對方法調用者造成任何英雄。
在充分了解到業務對象在應用中的重要性后，接下來需要關心的問題是，這些業務對象的狀態從何而來，當應用中指運行時，這些狀態被存放到什么地方。這就涉及到了對象的持久化問題。
4 業務對象的持久化
通常，持久化意味著通過手工或其他方式輸入到應用中的數據，能夠在應用結束運行后依然存在。即使應用運行結束或者計算機關閉后，這些信息依然存在。不管是大、中或、小型的應用，都需要數據的持久化。
4.1 對業務對象進行持久化的作用。
當應用中的業務對象在內存中創建后，它們不可能永遠存在。最后，他們要么從內存中清楚，要么被持久化到數據存儲庫中。內存無法永久保存數據，因此必需對業務對象進行持久化。否則，如果對象沒有被持久化，用戶在應用運行時發出的訂單信息將在應用結束運行后隨之小時。
關系型數據庫被廣泛用來存儲數據。關系型數據庫中存放的是關系型數據，它是非面向對象的。把業務對象映射到非面向對象的數據庫中，存在著阻抗不匹配（impedance mismatch），因此對象由狀態和行為組成，而關系型數據庫則由表組成，對象之間的各種關系和關系型數據庫中表之間的關系并不一一對象。例如對象之間的繼承關系就不能直接映射到關系型數據庫中。
4.2 數據訪問對象（DAO）設計模式
面向對象的開發方法是當今的主流，但是同時不得不使用關系型數據庫，在企業級應用開發的環境中，對象－關系的映射（Object-Relation Mapping，簡稱ORM）是一種耗時的工作。圍繞對象－關系的映射和持久化數據的訪問，在軟件領域中發展起來了一種數據訪問對象（Data Access Object，簡稱DAO）設計模式。
DAO模式提供了訪問關系型數據庫系統所需的所有操作的接口，其中包括創建數據庫、定義表、字段和索引，建立表間的關系，更新和查詢數據庫等。DAO模式將底層數據訪問操作與高層業務邏輯分離開，對上層提供面向對象的數據訪問接口。在DAO的實現中，可以采用XML語言來配置對象和關系型數據之間的映射。
對于Java應用，可以直接通過JDBC編程來訪問數據庫。JDBC可以說是訪問持久數據層最原始、最直接的方法。在企業級應用開發中，可以通過JDBC編程，來開發自己的DAO API，把數據庫訪問操作封裝起來，供業務曾同一調用。
如果數據模型非常復雜，那么直接通過JDBC編程來實現持久化框架需要有專業的知識。對于企業應用的開發人員，花費大量時間從頭開發自己的持久性框架不是很可行。通常，可以直接采用第三方提供的持久化框架，如ORM軟件產品。許多ORM框架都采用DAO設計模式來實現，為模型層提供了訪問關系型數據庫的API。
4.3 常用的ORM軟件
有許多ORM軟件可供選擇。有些是商業化的，有些是免費的。
不管是使用商業化產品，還是非商業化產品，都應該確保選用的ORM框架沒有“滲透”到應用中，應用的上層組件應該和ORM框架保持獨立。有些ORM框架要求在業務對象中印入它們的類和接口，這會帶來一個問題，如果日后想改用其他的ORM框架，就必需修改業務對象。
5 小結
這篇文檔介紹了模型的實現方法。Struts框架并沒有在模型層提供線程可用的組件。模型的實現應該和Struts應用的控制層以及視圖層保持獨立。
模型采用業務對象來描述狀態和行為，為了使業務對象持久化，需要把業務對象映射到關系型數據庫。
模型向客戶程序提供了業務代理接口，業務代理接口直接訪問持久化框架，處理實際的業務邏輯。Struts應用的Action類可以使用這個業務代理接口，而不必直接和持久化框架交互。這種做法有助于削弱上層Web應用和持久化框架之間的關系，提高持久化框架的相對獨立性。
閱讀材料：《精通Struts：基于MVC的Java Web設計與開發》
2005年05月12日 1:20 AM