struts 學習之04 “模型”

在這篇文章，我們繼續STRUTS，今天說說Struts裡面的模型組件，嚴格來說Struts裡面是沒有模型架構的，但它允許使用現成的其他模型架構，我們還是先來看看什麼是模型吧
模型代表應用的業務資料和邏輯。Struts架構並沒有為設計和建立模型提供現成的架構，因為在前面我們已經說過，Struts主要用於做UI層！不過，Struts允許使用其他模型架構來處理應用的業務領域，如EJB(Enterprise JavaBean)它裡面主要是實體Bean,，和JDO(Java Data Object),以及常規的JavaBean和ORM(Object-Relation Mapping)對象關係映射的Hibernate等等！
模型是應用中最重要的一部分，它包含了業務實體和商務規則，負責訪問和更新持久層化資料(這裡的持久化資料主要是針對ORM技術提出的)。應該把所有的模型組件放在系統中的同一個位置(也就是一般以***BO結尾的一個包)，這樣有利於維護資料的完整性，減少資料冗餘，提高可重用性！
模型應該和視圖以及控制器之間保持獨立。在分層的架構結構中，位於上層的視圖和控制器依賴於下層模型的實現，而下層模型不應該依賴於上層的視圖和控制器的實現！
因此如果模型組件中通過JAVA的import語句引入了視圖和控制器組件，這就違反了以上原則。下層組件訪問上層組件會使應用的維護，重用和擴充變的困難，這個和設計模式是一樣的！
不過在struts中有一個問題，就是我們在建立模型組件 的時候假如和Hibernate相關聯的話，Hibernate導過的類是整合序列化的一個介面！這樣的一個Project如果它和一個Struts表單相關聯的時候，因為struts表單它裡面必須是ActionForm,這樣的話我們轉換就有問題，這個時候就最好屐一個地方～就是將Hibernate Project繼承struts裡面的actionForm. 當然這樣做有點違反了規則，所以說struts架構，純MVC來說，因為它本身包含了MVC的所有部分，當然它是一種入侵式的架構，依賴性比較強，也就是我們用了它之後必須依賴它，但在商業化上用Struts還是比較多的，從外面企業對人 才的可知！畢竟商業上面對系統的穩定性要求比較高，有點像說遠了！和和～～
而在科學和工程技術領域，模型是一個很有用途的概念，它可以用來類比一個真實的系統。建立模型最主要的目的是協助理解，描述或類比真實世界中的目標系統的運行機制。我們建立一個系統的時候首先會建立模型。
在軟體開發領域，模型用來表示真實世界的實體。在軟體開發的不同階段，需要為目標系統建立不同的類型模型。在分析階段，需要建立概念性模型。在設計階段，需要建立設計模型。可以採用物件導向建模語言UML來描述模型！
在建立模型前，首先要對問題域進行詳細的分析，確定用例，也就是在模型建立前先要確定要用到的對象有哪些，接下來就可以根據用例來建立概念性模型。概念性模型用來類比問題域中的真實實體。概念性模型描述了每個實體的概念和屬性，以及實體之間的關係。但在這個階段並不描述實體的行為。
建立概念性模型的目的是協助更好地理解問題域，識別系統中的實體，這些實體在設計階段很有可能變成類
概念性模型清楚地顯示了問題域中的實體。不管是技術人員還是非技術人員都能看懂概念性模型，他們可以很容易地提出概念性模型中存在的問題，協助系統分析人員及早對模型進行修改。在軟體設計與開發週期中，模型的變更需求提出的越晚，所消耗的開發成本也就越大！

現在來看看業務對象：它有以下三種！
業務對象，即Business Object(BO),是對真實世界的實體的軟體抽象。它可以代表業務域中的人，地點，事物或概念！
業務對象包括狀態和行為，標識符（ID號）。
判斷一個類是否可以成為業務對象的一個重要標準，是看這個類是否同時擁有狀態和行為！
實體業務對象要算是最為人們所熟悉的。實體物件可以代表人，地點，事物或概念。通常，可以把業務領域中的名詞，例如客戶，訂單，商品等作為實體業務對象。在JAVAEE應用 中，這些名詞可以作為實體BEAN。對於 更普通的WEB應用，這些名詞可以作為包含狀態和行為的JAVABEAN。
而過程業務對象代表應用中的業務過程或流程，它們通常依賴於實體業務對象。可以把業務領域中的動詞。例如客戶發出訂單，應用等作為過程業務對象。在JAVAEE應用中，這們通常作為會話BEAN或者訊息驅動 BEAN。在非JAVAEE應用中，他們可作為常規的JAVABEAN，具有管理和控制應用的行為，過程業務對象也可以擁有狀態，例如在JAVAEE應用 中，會話BEAN可分為有狀態和無狀態兩種。（這個在EJB中也有，在建立EJB的會話BEAN時 會有兩種選擇，有狀態和無狀態！）
事件業務對象代表應用中的一些時間（如異常，警告或越時）。這些時間通常由系統中的某種行為處罰。例如，在JAVA Swing應用中，當客戶按下一個BUTTON，就會有一個事件業務對象產生，以便通知架構調用相關的時間處理器來處理事件

在應用系統中使用業務對象有許多好處，最重要的一點就是業務對象提供了通用的術語和概念，不管是技術人員還是非技術人員都可以共用並理解他們。它們可以直觀地代表真實世界中的概念，開發小組的所有成員都能理解他們。如果正對同一個業務領域需要開發出多個應用，那麼這些應用可以共用這些業務對象，業務對象的可重用特性可以提高應用開發速度。減少冗餘。
另外業務對象可以隱藏實現細節，對外只暴露介面。EJB即如此！
在充分瞭解到業務對象在應用中的重要性後，接下來需要關心的問題是，這些業務對象的狀態從何而來，當應用程式運行時，這些狀態被儲存在什麼地方。這就涉及到了對象持久化問題！
通常持久化意味著通過手工或其他方式輸入到應用中的資料，能夠在應用結束運行後依然存在。即使應用運行結束或者電腦關閉後，這些資訊依然存在。不管是大，中或小型應用，都需要資料持久化！
當應用中的業務對象在記憶體中建立後，糨們不可能永遠存在。最後，他們要麼從記憶體中清除，要麼被持久化到資料庫儲存。記憶體無法永久儲存資料，因此需要對業務對象進行持久化。否則，如果對象沒有被持久化，使用者在應用運行時發出的訂單資訊將 在應用結束運行後隨之消失。
 而關係型的資料庫被廣泛用來儲存資料。關係型資料庫中存放的是關係型 資料，它是非物件導向的。把業務對象映射到非物件導向的資料庫中，存在著阻抗不匹配(impedance mismatch),因此對象由狀態和行為組成，而關係型資料庫則由表組成，對象之間的各種關係並不一一對應。例如對象之間的繼承關係就不能直接映射到關係型資料庫中。
 而物件導向的開發方法是當今的主流，但是同時不得不使用關係型資料庫，在企業級應用開發的環境中，對象－－關係的映射(ORM)是一種耗時的工作。圍繞對象－－關係的映射和持久化資料的訪問，在軟體領域中發展起來了一種Data Access Objects(Data Access Object, 即DAO)設計模式！
 DAO模式提供了訪問關係型資料庫系統所需的所有的介面，其中包括建立資料庫，定義表，欄位和索引，建立表間的關係，更新和查詢資料庫等。DAO模式將 底層資料訪問操作與高層商務邏輯分離，對上層提供物件導向的資料提供者。在DAO的實現 中，可以採用XML語言來設定物件和關係型 資料之間的映射！
具體例子我放在Hibernate 初識 一文