三层CS技术方案
1.1.? 該方案的優勢
在支持互聯網應用中，BS和三層CS結構到底誰更合適？是一直以來爭論不休的問題。筆者認為這個問題應該根據不用的應用情況而定，對于E商這種連鎖行業的業務系統，筆者認為三層CS結構會更加合適。
| ? | BS結構 | CS結構 | 三層CS結構 |
| 跨地域、跨網絡 | 可以 | 不可以，只可以用于局域網，跨網絡應用時需要額外的投入，且應用效果不理想 | 可以 |
| 操作性 | 不好，網頁的操作方式對于大數量的操作效果不理想 | 好 | 好，在客戶端方面與CS結構的客戶端操作效果完全一致 |
| 服務器的壓力 | 非常大，所有的計算都在服務器上，所以服務器壓力非常大 | 小，客戶端分擔了部分計算壓力 | 小，與CS結構完全一致 |
| 網絡傳輸 | 速度慢，因為html的頁面有大量的冗余信息，必然會導致網絡流量大的問題 | 快，因為只需要傳輸數據 | 快，因為只需要傳輸數據 |
本方案另外一個顯著的特點是：該方案采用了三層CS結構，且在服務器端采用了Java服務器，客戶端采用了.net的開發技術，可以說是各取其所長。Java技術長于服務器，服務器的穩定性業界公認，常用于大型的系統，但java技術在客戶端的開發則劣勢明顯。微軟的.net開發框架則恰恰相反，微軟的中間件服務器，也就是IIS，其穩定性和安全性一直為業界所詬病，一般只用于中小型企業的業務系統，對于大型高并發的系統應用，則有點勉為其難。
所以，本方案在服務器但仍采用java服務器，可以與現有DRP采用同樣的服務器平臺，服務器的統一可以保證數據平臺的擴展性和數據統一性。對于客戶端我們采用了.net的開發框架，保證了客戶端良好的操作性，保證了用戶的良好使用感受和高效的工作效率。對于服務器和客戶端的通信，則由我們自行開發了通信接口，既保證了通信效率，也增強了報密性和安全性。
| ? | Java技術 | .net | 本方案 |
| 服務器 | 強，穩定性和安全性都經過了實踐的檢驗 | 差，微軟的中間件服務器的穩定性一致為業界詬病 | 服務器采用java技術 |
| 客戶端 | 差，客戶端開發一直是java的弱項 | 強，微軟一直擅長于用戶界面的開發 | 客戶端采用微軟.net技術 |
?
1.2.? 系統整體結構
系統為基于業界主流的三層架構技術：
l? 數據庫：支持SQL Server、Oracle等多種數據庫。
l? 應用服務器：可采用WebLogic、Tomcat等J2EE中間件，提供業務邏輯實現，數據存取，以及與外系統交互的各種接口。
l? 客戶端：采用基于.net 2.0的winform客戶端作為業務操作終端。
?
系統結構框圖：
1.3.? 系統中的對象
系統中數據存取涉及四種不同類型的對象：
PO:?全稱為presentation object，即表現層對象。通常在客戶端使用，用于界面控件的數據綁定。一個PO對象可能包含一個或多個VO對象，或者是VO對象的線性集合。PO對象出于展現數據的需要，往往還要添加各種冗余字段和計算字段。另外，PO對象通常使用事件與界面控件進行交互，以通知界面控件刷新。在.net平臺上，一般使用DataSet、DataTable和DataRow對象作為PO對象（請參考.net framework類庫的System.Data命名空間）。
VO:?全稱為value?object，即值對象，是僅僅包含數據的一種對象。通常用于業務層之間的數據傳遞，從數據庫讀取數據，以及將自身數據寫入數據庫等。與數據庫表的設計有密切關系。VO又常常被稱為“實體類”或“數據實體”。
DO:?全稱為data?access?object，即數據訪問對象，此對象用于訪問數據庫。通常和VO結合使用，DO中包含了各種數據庫的操作方法。通過它的方法，結合VO的數據對數據庫進行相關的操作.。
BO：全稱為business object，即業務邏輯處理對象。此對象用于處理具體的業務邏輯。通常，BO有一定的繼承層次，以提取一些公用的操作（如記錄日志等）。BO通常實現唯一接口，接收客戶端請求，調用DO更新數據，并以VO或VO集合的形式返回處理結果。
這三者分工不同，在簡單的小系統里面，可能有時會重合。但在大一點的系統里面，三者分工明確系統可拓展性，可維護性的好處，遠遠超出了前期編寫代碼時所付的代價。
?
1.4.? 數據存取技術
系統采用成熟的大型關系型數據庫管理系統作為數據存儲后端，同時使用基于面向對象思想的編程技術。
由于關系型模型和面向對象模型之間存在結構上的錯配，因此需要采用ORM技術對數據在數據庫和中間層之間進行轉換。iBatis是目前業界流行的一種ORM解決方案，其簡單、靈活、可靠的特點使得其得到了廣泛應用。
1.4.1.? ORM
對象關系映射（Object Relational Mapping，簡稱ORM）是一種為了解決面向對象與關系數據庫存在的互不匹配的現象的技術。 簡單的說，ORM是通過使用描述對象和數據庫之間映射的元數據，將java/.net程序中的對象自動持久化到關系數據庫中。
1.4.2.? iBatis
iBATIS是一個混合式的ORM解決方案（hybrid solution），借鑒了多種操作關系數據庫的方法的理念。
iBATIS的優點：
l? 簡單，學習成本低，容易掌握
l? 生產效率高，易于自動化
l? 性能
l? 提供對數據庫連接池、數據緩存、事務的統一管理
l? 分工明確，程序員和DBA可以各司其職，分工合作
l? 官方同時提供對java和.net平臺的支持
1.4.3.? 代碼生成
代碼生成的概念：
通過指定若干輸入參數，使用特定的軟件工具，使得計算機能自動地、批量地生成程序源代碼的過程。常用的代碼生成工具有“MyGeneration”、“CodeSmith”等。通常代碼生成工具都是基于模板和模板引擎技術，執行時，使用動態腳本語言根據輸入參數的不同，自動替換模板中的某些部分，從而生成大量邏輯相似的源代碼。使用jsp或asp.net腳本技術，也可以很方便的制作適用于特定目的的小型代碼生成器。
?
為什么要使用代碼生成技術：
l? 代碼生成非常高效。因為一旦制作好了合適的模板，設定了輸入參數，計算機可以在數秒內生成數萬至數十萬行的源代碼，效率是人工編碼的成千上萬倍。
l? 有利于代碼的標準化。通過合理規劃和制作模板，使得生成的源代碼的邏輯非常相似，代碼的結構、接口、處理過程容易標準化、通用化。通過修改模板，便可以批量地升級所有的生成代碼。
l? 有利于提高代碼質量。一方面，代碼的標準化使得性能調優變得更加容易。另一方面，減少了由于人工編寫而帶來的各種失誤。
l? 提高代碼適應能力。比如數據庫字段的增減在項目開發初期可能是比較頻繁的，如果由人工維護相應的數據存取代碼，則非常容易錯漏字段。通過使用代碼生成工具，只要輕輕點擊“重新生成”，便可使得代碼同步于外界環境的變化，減少了錯誤發生的可能。
?
代碼生成的適用場合：
由于不存在“萬能”的代碼模板，代碼生成一般適用于處理過程和處理邏輯比較標準的場合。通過使用基于iBatis的ORM框架，數據存取層的邏輯和編寫過程變得容易標準化，從而使數據存取層的代碼生成成為可能。
本系統中，數據存取層的VO、DO及相關的iBatis XML映射文件將應用代碼生成技術。
?
生成單表VO、DO：
這是最簡單的情況，代碼生成器將為指定的表生成對應的VO對象和DO對象。VO對象包含了數據庫表的所有字段，并且添加了必要的輔助字段和輔助方法。由于VO對象不包含業務邏輯處理，因此其所有數據域（Field）都是public的，目的是使代碼更精煉。DO對象提供了對關聯VO的四種基本操作：Select、Insert、Update、Delete。通過函數重載，為Select方法添加條件、分頁和排序的選項。
?
生成多表連接的VO、DO：
需要為此VO指定基本表。DO為基本表生成與單表VO類似的四種基本操作。對于關聯的其他表，需要指定連接的類型（join類型）和外鍵，代碼生成器會生成含join關鍵字的聯合查詢SQL及對應的SelectWith方法（With表示該查詢涉及多個表）。通過函數重載，為SelectWith添加條件、分頁和排序的選項。
?
條件檢索和條件刪除：
數據庫設計中，常常有物理主鍵和邏輯主鍵不完全一樣的情況。比如物理主鍵可能采用GUID，而邏輯主鍵可能是單據號，或者若干字段的組合。代碼生成器允許我們通過指定邏輯主鍵字段，生成相應的SelectBy、DeleteBy方法族。在多表連接時，還將生成SelectWithBy方法族用于聯合檢索。
?
條件更新：
在需要進行批量更新，或者需要使用邏輯主鍵進行更新的場合，可以為代碼生成器指定條件字段（通常對應于外鍵字段或邏輯主鍵字段），使其自動生成UpdateBy方法族。
?
部分檢索：
通常，在制作查詢界面時，并不需要羅列所有的字段，只要顯示若干主要的字段即可。或者，一些說明型或者二進制型的復雜字段，不需要在查詢結果中顯示（通常是在單據界面顯示這些復雜字段）。這個時候，為了提高響應速度和減小網絡流量，可以指定代碼生成器生成只檢索若干指定字段的查詢。代碼生成器將創建相應的SQL語句，使得數據庫只返回選定的字段，從而優化了性能。
?
部分更新：
在審核型的業務操作中，通常只對有限的幾個字段進行更新：主鍵、狀態字段和時間戳。這時我們可以指定需要更新哪些字段，則代碼生成器將創建相應的Update語句，使得只有指定的字段獲得更新，從而優化了性能。
?
數據分頁：
在三層或多層架構的軟件系統中，由于受客戶端到服務器的帶寬限制，數據分頁是很常見的一種操作，其目的是一次只返回“一頁”數據。通過在SQL語句中添加ROWNUM關鍵字，可以很容易地使分頁過程自動化。
?
直接執行動態SQL：
在實際的業務處理中，總是存在有難以標準化處理的情況，因此在系統中添加了對直接執行動態SQL的支持。該動態SQL可以是無返回值的（如Insert、Update或Delete操作，以及存儲過程調用），也可以是有返回值的（如Select操作）。返回值將以Hashtable（哈希表）結構返回。
?
1.5.? 中間層
中間層即應用服務層，部署于應用服務器上。中間層的主要作用是：
l? 響應客戶端請求，處理業務邏輯，返回響應數據
l? 執行數據庫存取操作
l? 通過部署Web Service，提供外系統接口
?
基于靈活性和可擴展性考慮，中間層采用MVC和Front Controller設計模式。
1.5.1.? MVC模式:
MVC（Model-View-Controller）模式是目前大型多層應用系統中主流的架構模式。MVC模式基于用戶輸入將域的建模、顯示和操作分為三個獨立的類：
l? 模型。模型用于管理應用程序域的行為和數據，并響應為獲取其狀態信息（通常來自視圖）而發出的請求，還會響應更改狀態的指令（通常來自控制器）。在系統中，模型對應PO和VO類對象。模型部分需要在客戶端和中間層之間傳遞數據。
l? 視圖。視圖用于管理信息的顯示。在系統中，視圖部分部署在客戶端，對應于.net WinForm 客戶端的各種窗體、控件。
l? 控制器。控制器用于解釋用戶的鼠標和鍵盤輸入，以通知模型和/或視圖進行相應的更改。控制器部署在中間層，包括一個前端控制器對象和一系列處理具體業務邏輯的命令對象。
?
使用MVC模式的優點：
l 同時支持多種客戶端。客戶端與中間層間使用XML進行通訊，中間層無需關心客戶端是winform、webform還是PDA。
l 適應更改。用戶界面要求的更改往往比業務規則快。將客戶端的邏輯與中間層相分離，使得界面更改不會影響到中間層和數據庫。
?
詳細技術資料，請參考“附件3：MVC模式”
1.5.2.? Front Controller（前端控制器）模式：
系統選擇Front Controller模式作為系統MVC架構下的控制器結構。
Front Controller 模式具有下列優點：
l? 集中化控制。Front Controller 用于協調向 Web 應用程序發出的所有請求，易于實施全應用程序范圍的策略，如安全性和使用情況跟蹤。
l? 線程安全。控制器為每個請求創建新的命令對象（業務邏輯處理對象），從而避免了線程安全問題。
l? 簡化配置。只需要在 Web 服務器中配置一個前端控制器便可執行各種調度。
?
詳細技術資料，請參考“附件4：Front Controller模式”
1.6.? 通訊技術
1.6.1.? 系統中各個模塊的通訊架構：
?
1.6.2.? Web Service：
Web Service是基于HTTP通訊協議和XML技術的一套分布式應用程序通訊框架。Web Service包含的主要技術有：
l? ?XML和XSD： 可擴展的標記語言XML 是Web Service平臺中表示數據的基本格式。除了易于建立和易于分析外，XML主要的優點在于它既與平臺無關，又與廠商無關。XML是由萬維網協會 (W3C)創建，W3C制定的XML SchemaXSD 定義了一套標準的數據類型，并給出了一種語言來擴展這套數據類型。Web Service平臺是用XSD來作為數據類型系統的。當你用某種語言如VB.NET或C# 來構造一個Web Service時，為了符合Web Service標準，所有你使用的數據類型都必須被轉換為XSD類型。如想讓它使用在不同平臺和不同軟件的不同組織間傳遞，還需要用某種東西將它包裝起 來。這種東西就是一種協議，如 SOAP。
l? SOAP：SOAP即簡單對象訪問協議(Simple Object Access Protocol)，它是用于交換XML編碼信息的輕量級協議。它有三個主要方面：XML-envelope為描述信息內容和如何處理內容定義了框架，將 程序對象編碼成為XML對象的規則，執行遠程過程調用(RPC)的約定。
l? Web Service描述語言-WSDL。WSDL 就是用機器能閱讀的方式提供的一個正式描述文檔而基于XML的語言，用于描述Web Service及其函數、參數和返回值。因為是基于XML的，所以WSDL既是機器可閱讀的，又是人可閱讀的。
l? UDDI：UDDI 的目的是為電子商務建立標準；UDDI是一套基于Web的、分布式的、為Web Service提供的、信息注冊中心的實現標準規范，同時也包含一組使企業能將自身提供的Web Service注冊，以使別的企業能夠發現的訪問協議的實現標準。
l? 遠程過程調用RPC與消息傳遞
?
1.6.3.? 對象序列化技術：
在面向對象系統中，數據的操作都是通過對象完成的。在分布式應用中，需要通過對象序列化技術，將對象轉換為可以通過網絡傳遞的字節流，傳送到遠端。遠端使用反序列化技術，將網絡字節流還原為對象，完成數據傳遞。
通常的對象序列化技術有兩種：
1.??????? 二進制序列化：以二進制格式記錄對象的所有數據域的值。序列化的結果為字節數組。
2.??????? XML序列化：以XML文本的形式記錄對象的所有數據域的文本值。非字符串類型的數據域將需要轉換為對應的文本。序列化的結果為字符串，在網絡上傳送的實際是該字符串對應某個特定字符集（如GB2312）的字節流。
性能上二進制序列化要高一些，但是受特定技術平臺的限制。XML序列化由于存在XML和文本解析的過程，性能要低一些，但是可以跨技術平臺使用，而且可讀性較好。
考慮到本系統需要跨越java和.net平臺，以及將來可能需要部署各種對外接口，基于標準化和統一化考慮，本系統決定采用XML序列化技術。
?
1.1. 附：ORM技術
對象關系映射（Object Relational Mapping，簡稱ORM）是一種為了解決面向對象與關系數據庫存在的互不匹配的現象的技術。 簡單的說，ORM是通過使用描述對象和數據庫之間映射的元數據，將java程序中的對象自動持久化到關系數據庫中。本質上就是將數據從一種形式轉換到另外一種形式。 這也同時暗示著額外的執行開銷；然而，如果ORM作為一種中間件實現，則會有很多機會做優化，而這些在手寫的持久層并不存在。 更重要的是用于控制轉換的元數據需要提供和管理；但是同樣，這些花費要比維護手寫的方案要少；而且就算是遵守ODMG規范的對象數據庫依然需要類級別的元數據。
?對象-關系映射，是隨著面向對象的軟件開發方法發展而產生的。面向對象的開發方法是當今企業級應用開發環境中的主流開發方法，關系數據庫是企業級應用環境中永久存放數據的主流數據存儲系統。對象和關系數據是業務實體的兩種表現形式，業務實體在內存中表現為對象，在數據庫中表現為關系數據。內存中的對象之間存在關聯和繼承關系，而在數據庫中，關系數據無法直接表達多對多關聯和繼承關系。因此，對象-關系映射(ORM)系統一般以中間件的形式存在，主要實現程序對象到關系數據庫數據的映射。
面向對象是從軟件工程基本原則(如耦合、聚合、封裝)的基礎上發展起來的，而關系數據庫則是從數學理論發展而來的，兩套理論存在顯著的區別。為了解決這個不匹配的現象,對象關系映射技術應運而生。
讓我們從O/R開始。字母O起源于"對象"(Object),而R則來自于"關系"(Relational)。幾乎所有的程序里面，都存在對象和關系數據庫。在業務邏輯層和用戶界面層中，我們是面向對象的。當對象信息發生變化的時候，我們需要把對象的信息保存在關系數據庫中。
當你開發一個應用程序的時候(不使用O/R Mapping),你可能會寫不少數據訪問層的代碼，用來從數據庫保存，刪除，讀取對象信息，等等。你在DAL中寫了很多的方法來讀取對象數據，改變狀態對象等等任務。而這些代碼寫起來總是重復的。
對象關系映射成功運用在不同的面向對象持久層產品中，如:Torque,OJB,Hibernate,TopLink,Castor JDO, TJDO 等。
一般的ORM包括以下四部分：
一個對持久類對象進行CRUD操作的API；
一個語言或API用來規定與類和類屬性相關的查詢；
一個規定mapping metadata的工具；
一種技術可以讓ORM的實現同事務對象一起進行dirty checking, lazy association fetching以及其他的優化操作。
總結
- 上一篇： 23种设计模式-行为型模式-访问者模式
- 下一篇： 华为人力资源管理经典大全