一套較完整的技術框架
1 引言
1.1 前言
本文將基於目前現有的軟件開發架構（以下簡稱‘架構’）（Packer for Delphi），同時如何合理地引進新技術等問題，進行系統地分析和研究，以指導新架構的研發。
1.2 研發依據
1.2.1 公司發展
1.2.2 開發方式
1.2.3 技術升級
1.2.4 產品線
行業領域軟件需要個性化的服務，如果對應以作坊式的開發方式，將會陷於項目越多，版本也越多，維護成本也隨之上升的局面。
針對行業領域軟件特點，在以產品線爲設計思路的業務架構建設中，需要對應的技術架構來配合完成。
1.3 研發前提
1.3.1 公司產品開發的範圍
1.3.2 軟件開發架構在產品開發中所處的位置
軟件開發架構，是一個承上啓下、集成應用開發領域的通用的各種技術而形成的一整套的開發體系框架，它包括如下的幾個方面：
1、可持續的框架體系：
一個用於明確管理界定各種功能及其關係的框架體系，每個功能點在架構中由於其特性必然有着明確的位置，各種相關技術也由架構來完成其相互的無縫接入。並且通過這種可持續化的特徵，能將技術的、業務的工作管理起來，並持續的發展。
2、技術的集成和整合：
隨着應用領域的拓寬，這些技術會不斷的拓展，包括如：工作流技術，安全技術，消息服務技術，即時通信技術，門戶技術，數據交換技術，全文檢索技術等等。說到集成，就是指除了這些技術本身之外，架構提供對這些技術的整合，將這些技術本身放在整體框架的某個部分和層次。技術的整合不是簡單的拼裝，做得好壞，取決於長期的經驗和技術的積累，否則再好的技術，整合起來往往得到的是最差的東西。
3、更爲細節的規範：
爲了程序的易於理解和維護，便於細化分工，架構將儘可能的減少異化，儘可能的標準化開發過程和代碼格式。這些規範可能會細化到如：打開關閉連接的時機，命名空間的管理，文件名稱的定義，代碼縮進的長度，使用的開發和設計工具等等這樣非常細節化的東西，從而保證一致性。
4、標準、簡單，機械化的開發過程：
追求將開發過程1234化，避免思維的漏洞，將思維上的一種或者幾種有效的開發套路固定爲外在的規範，並且通過一系列的工具將其持久化。
5、最終的追求－－軟件生命週期的管理：
這樣的一個架構，最終追求的是對一個完整的軟件生命週期的管理，不僅僅是開發的過程，還包括規劃，需求，設計，測試等一系列的過程。
總之，架構是爲應用系統的開發，提供一套集成的、適合自身軟件開發過程的技術規範、開發準則、通用組件、輔助工具等等，使得應用系統的開發更加高效、方便、統一，爲軟件大生產的開發提供物質保障。
1.3.3 技術平臺的選型
開始架構研發之前，必須先對架構的基礎－技術平臺，進行選型，否則將是無本之木，一紙空談。
縱觀當前流行的技術平臺，不外乎兩大陣營：J2EE和.NET，以下是針對幾個指標進行的一個評價：
J2EE
.NET
開放性
好
差
應用範圍
Web應用
Web應用或者非web應用
開發工具成本
低廉（開源）
一般（專用）
開發資源成本
高
一般
開發效率
週期長
快速
運行性能
差
一般
運行資源成本
高（捆綁專用服務器）
低（分佈式PC服務器）
部署效率
差
一般
界面豐富與靈活性
差
高
與服務商綁定
高（SUN、IBM）
高（MS）
關於J2EE和.NET之間的討論已經持續很多年了，而且也將繼續爭論下去，孰優孰劣仍然很難下結論。
適用的纔是好的，作爲IT企業，從公司產品的受衆、研發、推行、維護的成本與收入等等上來考慮，自然會得到一個明確的答案。
對於ERP等生產管理系統，系統性能、豐富的表現與交互界面是關鍵的技術要求之一，在非web應用的軟件研發上將主要基於.NET開發平臺。
同時，爲了兼顧效率，可以結合Win32的開發工具（Delphi/C++）開發部分實時性要求很高的應用系統，對於這點，.NET自身可以很好的與Win32進行整合。
1.4 系統名稱
1.5 中期計劃
1.6 資源計劃
2 參考文獻
3 功能分析
通過分析歸納，技術架構的開發，只要針對如下幾大項的功能點進行研發，基本上可以支持目前所遇到的大部分技術需求：
項目
內容
支持雙語
雙語是指開發出來的應用系統，應該在表現層上，只要根據用戶的簡單選擇，就能提供中文、英文之一種語言顯示效果。
提供對雙語的技術支持，方便開發人員通過配置工具配置應用系統相關的屬性（提示信息、按鈕標籤、數據標籤等等），而在代碼設計中只需對相關組件進行簡單的定義，即可實現此功能。
數據字典
數據字典是對應用系統用到的所有數據項和結構的定義，以確保開發人員使用統一的數據定義。
本數據字典不僅包含數據庫數據字典部分內容，而且進行了擴充，比如表字段的雙語標籤等的屬性定義，再外延出去的話，還包括公共代碼的統一管理等。
數據字典是技術架構與系統業務分析的基礎，比如數據動態、持久層中的自動構建數據集、自動操作數據庫等等功能，都要用到數據字典。
持久層
對象化存儲就是將數據庫中的數據在對象中實例化，當修改這個對象的屬性時，數據庫中的相應字段也會隨之改變，通常叫做持久層。
持久層應該提供事務管理、鎖機制、緩存機制。
數據動態
將應用系統中發生的數據變化，實時通知需要獲知變更的組件中，使得數據在需要同步的組件中保持一致性。
安全管理
對應用系統的登陸用戶進行校驗與權限上的管理，包括菜單、按鈕、記錄的增刪減等等。
支持工作流模式。
日誌管理
對應用系統中敏感數據的更新，必須持久化，記錄由何人、何時、何地（IP）和數據的新舊變更，以便跟蹤。
應用系統中，由數據庫、中間層、客戶端所產生的陷阱信息都歸到日誌管理中。
日誌按照日誌類型、輕重程度、緩急程度等分級（可以由用戶自定義），並設置日誌發送的目的地：本地、數據庫、監控中心、手機等等。
用戶界面框架
總結表現層常用的界面模式，歸整爲統一的組件或模板，方便開發，統一應用系統的界面風格。
客戶端組件框架
客戶端的開發，關注於主程序、界面組件、工作間組件等。
主程序以EXE形式實現，而其餘組件以DLL形式實現，主程序通過響應菜單來驅動組件運行。
必須規範主程序與組件間的接口。
服務端組件框架
服務端的開發，關注於主程序和業務組件。
主程序以EXE形式實現，而其餘組件以DLL形式實現，主程序通過響應客戶端來驅動組件運行。
必須規範主程序與組件間的接口。
通用報表
用戶可以自定義報表，用戶自定義的報表模板可按功能（樹狀層次）保存供以後或其他用戶重複使用。
報表不僅要輸出到打印機，而且應該能輸出到Text、RTF、PDF、Excel、Word、HTML等等文檔格式，並能夠通過Email發送出去。
報表可以人爲增加、刪除列表項，人爲將列表項重新排列、進一步搜索列表項等等。
工作流
工作流是針對工作中具有固定程序的常規活動而提出的一個概念。
通過將工作活動分解成定義良好的任務、角色、規則和過程來進行執行和監控，達到提高生產組織水平和工作效率的目的。工作流技術爲企業更好地實現經營目標提供了先進的手段。
協同性
協同性在物流系統的管理上非常重要，很多作業需要多角色的配合來完成，因此在應用系統的實現上，需要考慮協同性問題，以方便用戶工作。
各部門、各人員，以及企業和外部資源之間可以共享信息、實現即時溝通和協同運作，大大提升運作效率，減少企業管理和運營的成本。
應用系統發佈策略
對應用系統的發佈採取許可授權（license）的方法，可避免應用系統被盜用或者超範圍使用，以保護公司的知識產權。
應用系統的升級，用戶應該少受到影響，並且儘可能方便。
負載均衡
應用服務器應該具有可擴展性，即達到分佈式。
在多個應用服務器提供服務的情況下，客戶端連接服務器的策略，應該達到均衡連接，而一旦某臺服務器當機時，客戶端可以自動嘗試連接其他服務器。
4 總體框架
4.1 分佈式C/S/S框架
非web應用系統，將在基於分佈式的C/S/S框架下進行開發。
分佈式C/S/S框架和傳統的C/S框架之不同點，在於客戶端和數據庫之間加入了應用服務器這一中間層。
4.1.1 優勢
使用分佈式C/S/S框架具有如下的優勢：
1， 減輕處理器的負荷
主要是爲了減輕數據庫的負荷，由相對價廉的應用服務器來分攤其運算負荷。
2， 可伸縮性的要求
如果業務設計正確，業務邏輯就能夠被複制和分佈到幾個負載均衡的應用服務器上，如果用戶數量增加，則可以添加更多的服務器以滿足需求。
3， 部署和可維護性的要求
分佈式架構下的客戶機，可以做到在啓動時通過應用服務器進行自我更新；另外，添加功能模塊也更容易些。
4， 稀有資源的共享
應用服務器將稀有資源（比如數據庫連接）放在緩衝池中，這樣可以在多個客戶機上共享它們。
4.1.2 負載平衡
分佈式計算最大的問題是如何做到負載平衡。基於計算中一個簡單的事實：調用不同進程上對象的方法要比調用進程內對象的方法慢數百倍，如果將對象移到網絡中的另一臺機器上，這種方法調用又會慢數十倍。
所以，在應用系統的業務設計（技術架構與業務架構的關聯）上須從以下幾點考慮：
1， 客戶機上不一定是絕對和業務邏輯無關，數據庫也絕對不是不能處理業務邏輯，而應該遵循‘相關內容本地化’的原則，靈活處理；
2， 遠程對象應該提供粗粒度的接口，以減少在網絡中的信息交互量；
3， 優先選用無狀態的對象，以提高系統可擴展性，爲多應用服務器的負載平衡機制提供條件。
只有在應用系統的業務設計上，做到了上述幾點要求，那麼整個系統的性能就可以得到保障，否則用什麼架構都是徒勞無益的。
另外，針對多應用服務器的負載平衡，本架構在客戶端的登陸處理方式上，提供一套機制，使得客戶端啓動時，自動登陸到負載最輕的一個應用服務器上。
4.2 基於組件開發
基於組件的開發是個方法論框架，對於指導我們如何建設：開發體系結構、技術體系結構、應用體系結構和項目管理系統結構，都有很大的幫助意義。
採用這種方法，開發生命週期中的所有問題和階段，包括需求分析、體系結構、設計、構建、測試、部署、支持技術基礎設施和項目管理，都將是基於組件進行。
4.2.1 基於組件開發的益處
1， 控制開發複雜性
可以提供劃分業務領域的極佳方法，開發過程是通過組件組裝大規模系統而不是構建這些系統。
2， 改變應用系統的本質
按照用戶的視點開發組件並組裝系統，從而帶來市場推銷和購買軟件解決方案的新方式。
3， 實現部件的自治開發
應用系統以一組準自治部署單元構成，從而支持新的和富有挑戰性的高層併發開發、測試和部署。爲此將改變開發模式和組織結構，由業務領域和專業領域來劃分產生基於接口協同的自治開發小組（技術架構與組織架構的關聯），而項目的運作則是依照訂單來定購這些組件進行組裝。
4， 控制部署複雜性
特別體現在系統的演化（變更）過程中，因爲系統的修改和更正只會影響一個組件。
5， 縮短產品投放市場所需的時間
成熟的基於組件的開發會大大縮短軟件的開發週期，基於組件的開發很容易通過現有的組件組裝新的系統。
4.2.2 基於組件開發的層次
1，分佈式組件
從粒度角度看，分佈式組件是最小的組件，具有可通過網絡尋址的接口，通常採用商品化的組件實現技術（例如CORBA、EJB、.NET Remoting或DCOM等）實現。
這種設計模式的目標是支持大規模分佈式系統的高生產率開發。
定義分佈式組件的方式，使概念設計人員和開發人員只需要關注描述接口、編寫業務邏輯、定義到持久存儲的映射以及調用其他分佈式組件的服務，從而降低功能開發人員的工作複雜度。
2，業務組件
業務組件是自治業務概念（實體或過程）的軟件實現。業務組件包含把給定業務概念表示、實現和部署爲更大分佈式信息系統的自治、可重用要素所需的全部軟件工件。
具有各種體系結構原則和概念的業務組件可以用任何語言實現，雖然當前的商品化的建模工具和組件實現技術並不直接支持業務組件概念，但業務組件是一種極爲有力的邏輯概念，可以用來降低大規模開發的複雜性，獨立於下層開發環境的支持級別。我們可以在不同程度上採用業務組件概念，都會帶來可觀的開發效益。
業務組件開始是需求階段的一種單個結構，到了部署、配置和維護階段，仍然是同一個單元。從這個意義上說，業務組件概念涵蓋了整個開發生命週期。
3，業務組件系統
描述業務組件之間的協同關係，是對業務組件的組裝，提供了針對某個業務問題的解決方案。
業務組件組裝作爲開發、測試、部署和發佈單元是很有用的。不僅如此，業務組件組裝還可以看作是一種進化或維護單元，即通過一個單一操作，就可以用新版本替換整個業務組件組裝。
4.2.3 基於組件開發的開發過程
基於組件的開發過程有以下10個黃金特徵：
1， 以組件爲核心
在整個開發過程，以及所有的體系結構考慮和業務組件方法的所有其他問題，都圍繞不同級別粒度的組件展開。
2， 以體系結構爲中心
在整個開發生命週期都採用系統結構視點推動系統的進化。
3， 關注自治
在每個開發生命週期階段，都必須在適當的層次上採取關注自治性的步驟。
4， 向協同發展
在關注自治的同時，實現高水平的協同。一方面，要對單個業務組件進行自治的分析、設計、實現和測試，另一方面又需要保持系統作爲一個整體的完整性，保持這種不同自治單元之間的各種潛在協同的完整性。
5， 迭代特性
開發過程通過自治地實現和進化單個組件，支持具有明顯迭代和漸進特徵的過程。爲了支持這種過程具有成本效益，開發環境理念必須支持整個生命週期內的快速迭代。
6， 高水平的併發開發
前面的特徵支持獨立團隊彼此互相獨立和併發地設計、開發和測試系統部件，同時仍然保持整個系統的完整性。這是快速開發的一個基本要素，並直接支持經濟地完成軟件製造的目標。
7， 持續集成
功能開發人員應該能夠持續地開發系統部件，並立即得到有關係統功能和行爲的系統級反饋，同時又要把注意力集中在構建系統的功能上，而不是技術細節上。
8， 支持風險管理驅動的開發
倡導對項目狀況進行立即反饋，以便不斷驗證和確認各種設計和實現決策；倡導小型、快速迭代，採用合適的工具和過程管理。
9， 突出強調重用
重用要運用於生命週期從需求開始的所有階段。
10， 把組件開發作爲產品開發
業務組件是在儘可能多的地方重用的產品，好的產品開發的突出特徵，是十分關注質量、文檔和支持。交付的產品應該具有“活的文檔”的特徵，即總是保持最新狀態的文檔。
4.3 基於組件開發的分層框架
在分佈式C/S/S框架下，可以實現基於組件的分層設計。
4.3.1 分層
層（layer）：層是對架構的橫向劃分，對模型中同一抽象層次上的包進行分組的一種特定方式。通過分層，使系統以更鬆散的方式耦合，從而更易於維護。分層是對系統邏輯上的分層，在實際應用中將根據系統效率、負載平衡等等實際情況，變通、權衡地實現具體的應用。
我們將應用系統的設計劃分爲：表現層、業務層、持久層等，在這些層上分別構建相應的組件框架，以利於方便和規範應用系統實現分層框架。
表現層包含‘客戶端界面組件框架’，業務層包含‘客戶端業務組件框架’、‘服務端業務組件框架’，持久層包含‘數據集持久化引擎’；而‘工作流引擎’、‘數據動態引擎’、‘消息引擎’、‘安全引擎’等是橫跨表現層、業務層和持久層。
以下將按照分層和引擎分別表述。
4.3.1.1 表現層
表現層是用戶和應用系統進行交互的接口。它輔助用戶輸入，提供各種提示和幫助、響應用戶操作所觸發的各種事件、限制用戶的輸入、處理一些特殊的操作等等。
在表現層上，需要提供一整套的支撐模塊和組件框架，以統一界面風格、設計模式。
4.3.1.1.1 分類描述
1， 窗體模版
通過項目和產品實踐中不斷的積累，逐步歸納整理出一套具有自身特色的標準模版：主窗體、多窗體、對話框窗體、數據處理窗體、查詢打印窗體等等。
2， 客戶化定製
用戶可以自定義界面風格、自定義操作風格、自定義數據顯示與輸出模式。比如：報表可以由用戶自定義，而且可以將自定義模板持久化到本地或配置庫中供其他用戶使用等等。
這些定製化的功能，需要第三方界面控件的配合來完成，必要得話，要對這些控件進行二次開發。
3， 導向型界面框架
有些界面之間存在明確的處理順序，用戶可以選擇‘上一步’、‘下一步’或者‘結束’，界面之間的跳轉是由用戶觸發的，用戶的操作流程可以用一張流程（導航）圖來描述，導航圖上每一個節點就是一個用戶界面。爲此，可以通過這樣一個流程控制器，以隔離界面與業務邏輯，對流程中的界面進行管理，提供狀態保存和傳遞的機制。
本框架是工作流引擎在客戶端上一個獨立的外延子項，核心組件爲通用的流程控制器和狀態機，狀態信息的持久化在本地，以便恢復導航圖中每個節點的當時狀態。另外，利用這個組件，也可以在系統正常退出時保存界面狀態，以便重啓客戶端時，將界面恢復到當初退出時的狀態。
導向型界面是解決單個用戶的多步操作行爲，如果每步的界面是由不同的用戶來操作的話，就得靠消息驅動來提供作業的導航了。
4， 消息驅動型界面框架
一個任務可以由多位用戶協作完成，當前一個用戶完成自身的工作後，可以將此任務傳遞到下道工序的用戶，任務通過流程控制器進行流轉。消息驅動型的界面，使得用戶的操作是由消息來推動，任務是分派來的而不是主動去找的。爲隔離界面與業務邏輯，通過流程控制器對消息驅動型界面進行管理，提供狀態保存和傳遞的機制。
本框架是工作流引擎在客戶端上的一個關鍵子項，核心組件爲通用的流程控制器和狀態機，狀態信息的持久化在配置庫，以便恢復導航圖中每個節點的當時狀態。
本框架的具體實際機制，將由最終選用的工作流引擎來定，將在下面的專題章節中單獨討論。
5， 整合第三方表單控件
第三方表單控件，是相對圖形化控件而言，分普通窗體控件和數據感知控件。
第三方表單控件的引進，必須遵照少而精的策略，如果開發工具本身自帶的控件已能滿足開發需求，那麼就不要再使用相同功能的第三方控件，花哨實無必要。
目前可以嘗試引進的第三方界面控件，大致如下:
ComponentOne Studio for.NET；
Developer ExpressComponent for .NET；
6， 整合第三方圖形控件
我們所開發的產品，80％的界面將是圖形化交互模式，不僅僅要畫出無數各種形狀和顏色的小圖形，而且這些圖形也是一個個對象，需要隨時根據動態刷新數據變換顏色、形狀、位置等等，另外，它又是可以與用戶進行交互的，可接受鼠標的點擊、選擇、聚焦、拖放、獲取屬性等等。
在現有產品中，我們已經成功地使用了第三方的控件： TATUK GIS for VCL，積累了不少的開發經驗。在.NET開發平臺上，也有該產品線：TATUK GIS for .NET，所以，相信目前的產品可以平滑地遷移到新的技術平臺上。
7， 整合第三方報表控件
用戶可以自定義報表，人爲增加、刪除列表項，人爲將列表項重新排列、進一步搜索列表項等等，用戶自定義的報表模板可按功能（樹狀層次）保存供以後或其他用戶重複使用。
報表不僅要輸出到打印機，而且應該能輸出到Text、RTF、PDF、Excel、Word、HTML等等格式文件，並能夠通過Email發送出去。
一些第三方的表單控件，可以將數據列表輸出到打印機和各種格式的文件中，此處專門討論專業報表控件，除了VS2005自帶的Crystal Reports（水晶報表）外，目前可以嘗試引進的第三方報表控件有：
ActiveReports for .NET；
Grid++Report（COM組件）；
8， 動態菜單
沿襲Packer for Delphi中的模式，應用系統的菜單可以通過配置工具定義的內容進行動態構建。
當菜單項與客戶端業務組件進行關聯後，業務組件就可以被自動調用（通過客戶端業務組件框架）；當業務組件與安全引擎進行關聯後，菜單項的Enabled和Visible屬性都能被自動設置。
動態菜單的設計，將繼承自VS2005自帶的菜單控件，分標準菜單和樹狀菜單兩種。
4.3.1.1.2 智能客戶端
智能客戶端（Smart Client）是微軟爲開發表現層而提供的一套‘集成式桌面框架’，聲稱將淘汰掉基於瀏覽器的開發模式，雖說是針對web應用，但將客戶端開發迴歸到桌面，保持豐富的表現性和互操作性，是我們所需要的。
智能客戶端包含了一些基本服務：上下文服務、部署服務、安全服務、集成服務等等。
4.3.1.2 業務層
業務邏輯層，有人把這一層叫做業務基礎平臺，或者叫做領域框架層。這一層是針對某一行業或特定類型應用的通用的軟件實現，具有業務的通用性。它可以更高程度地實現軟件的複用，同時又支持用戶的個性化需求的實現，能夠快速地開發用戶所需要的應用系統。而基於組件的開發方式是爲達到此目的的唯一實現過程。
如何構建業務層，必須從服務、組件、對象三個層次分析問題，服務包含了組件、組件包含了對象，對象在組件中被複用，組件在服務中被複用，而對象、組件、服務的關係必須是鬆耦合的。爲做到這點，按照面向對象的方法，核心功能一般被實現爲一組以特定方式交互的抽象的類，在導出具體的應用時，這些抽象的類由特定的具體子類替換。而從組件和服務的觀點來說，這些抽象類就是接口。總之，接口是構建業務層的關鍵點。
爲了實現業務層，我們抽象出一層來通過接口協調其中的對象、組件、服務，這就是業務組件容器，它是組件運行時所處的空間，負責組件的生命週期管理以及組件運行需要的上下文管理。當用戶希望執行一個業務的時候，我們可以要求容器創建這個業務對象，業務容器可以交給我們一個業務對象的代理，隱藏真實的對象的位置。實際的執行過程可能是分佈式的，容器爲我們管理業務對象的事務性，保存業務執行的進度，必要的時候暫停業務，條件成熟後再重新開始，業務完成以後將對象銷燬……這些我們都不必關心，由容器爲我們做。
按照分佈式系統的物理實現，將業務層中的組件分爲：客戶端業務組件、服務端業務組件，它們都由業務組件容器統一管理和調配。客戶端業務組件框架是客戶端業務組件的容器，提供與客戶端界面組件和服務端業務組件的標準接口；服務端業務組件框架是服務端業務組件的容器，提供與客戶端業務組件和持久層引擎的標準接口。
4.3.1.2.1 客戶端業務組件框架
沿襲Packer for Delphi中的模式，基於DLL的插件框架將被遷移到基於程序集的插件框架。它們沒有本質的區別，只是.NET的程序集爲組件開發提供了更方便的開發環境和調試環境，同樣也方便了組件的部署。
組件框架爲應用系統開發提供標準的接口，當應用系統需要創建某個業務對象時，組件框架利用.NET的反射機制，通過接口動態加載相關的程序集並啓動這個業務對象。缺省情況下，組件框架會傳遞給這個組件當前應用系統的用戶權限等等信息；同樣，調用方和被調的組件之間，也可以通過接口傳遞消息、數據、對象等。
程序集可以實現動態插拔，只需更改配置信息（事先被持久化到本地或配置庫中）和XCOPY相應的組件，就可以無須編譯直接定製出一個特定的應用系統。
客戶端業務組件與服務端業務組件之間的聯繫，是採取請求服務和提供服務的方式處理的。
4.3.1.2.2 服務端業務組件框架
服務端業務組件通過遠程組件容器供客戶端調用。.NET框架有兩種組件容器供遠程調用：XMLWeb服務和.NET Remoting。
.NET Remoting 和JAVA的RMI一樣，允許開發人員將網絡中獨立機器上的組件（程序集）連接起來構成應用程序，前提是假設是在一個同構環境中，假定.NET應用位於通信通道的兩端。
XMLWeb服務可以使Web站點和應用程序之間象組件（程序集）那樣互相作用，跟所有的組件（程序集）一樣，Web服務也是通過一些方法來提供它的功能。與.NET Remoting不同的是，Web服務被設計爲可以在異構環境中工作。
XMLWeb服務和.NET Remoting有許多相似之處，它們共享許多諸如SOAP和WSDL等組件（程序集），而且ASP.NET可以駐留遠程對象，並通過HTTP通道使用SOAP串行化技術來提供這些對象，使得遠程對象看起來就象是個Web服務。但是，它們是根本不同的技術，.NET Remoting使用串行化機制來保持CTS（Common Type System，即.NET通用類型系統）類型的可靠性，而Web服務使用串行化機制來保持XML Schema（XML文檔類型系統）類型的可靠性。正因爲如此，當知道客戶端僅是.NET客戶端時，使用.NET Remoting比較合適，而如果還需要支撐很多類型的客戶端平臺時，Web服務會更適合這項工作。
一般而言，信息系統對外的接口，或者信息系統內的子系統之間接口，可以採取XMLWeb服務的方式（即SOA架構）；而子系統內則採取.NET Remoting方式。
1，效率分析策略
從系統效率考慮，.NET Remoting提供了HTTP和TCP兩種通道、SOAP和二進制兩種傳輸格式，可互相組合使用，而且還可以在一個服務器上同時註冊一個HTTP通道和一個TCP通道，以滿足不同的需要。
TCP通道利用TCP/IP網絡協議提供了連接性，默認情況下，信息被轉換成二進制格式，二進制有效負荷相對而言比較小，因此TCP通道與HTTP通道相比執行起來更容易。不過，TCP通道需要在服務器上建立唯一的網絡端口，這點以及他專門的二進制格式，在傳送方法調用時，要通過防火牆會比較困難。不過，在一個封閉的網絡環境（也就是說在防火牆後面）中，要獲得性能更好的連接性，首選TCP通道。
HTTP通道利用HTTP網絡協議提供連接性，在Web服務器和Web瀏覽器間也使用HTTP協議。默認情況下，信息被轉換成SOAP格式，由於SOAP基於XML語言，有效負荷會更大一些，因此HTTP通道比TCP通道執行起來要慢一些。但從另一個角度來說，也更要靈活一些。例如，IIS可以作爲遠程對象的主機，並在HTTP通道中提供這些遠程對象。因爲IIS是在端口80（所有Web服務器的默認端口號）進行監聽，不需要再打開一個新的端口來提供對遠程對象的連接。而且，防火牆的通常配置容許80端口的請求，因此如果要更順利地通過防火牆，首選HTTP通道。
爲了將TCP通道的速度和HTTP通道的靈活性進行折中，可以使用帶有二進制格式化的HTTTP通道。這樣可以爲IIS駐留遠程對象提供靈活性，還可以使之很容易地通過防火牆。不過，TCP通道本身比HTTP通道更有效，因此，TCP通道/二進制格式化的組合還是要比HTTP通道/二進制格式化的組合更快一些。
另外，.NETRemoting的調用機制有同步和異步之分，當客戶端需要及時響應用戶操作的情況下，可以選用異步方式（委託）調用遠程對象。
2，駐留遠程對象策略
上述提到的IIS駐留遠程對象方式是一種，另外還可以駐留在Windows服務中。
Windows服務可以在機器重啓時自動啓動，並且可以使用一個特定的用戶帳號執行，也不會干擾本機上的其他用戶，這些特點都使得Windows服務非常適合於駐留遠程對象。
3，編組遠程對象策略
.NET以兩種不同的方式編組對象：通過值編組（MBV）和通過引用編組（MBR），從概念上講，這些編組技術與通過值和通過引用傳送參數的表示法是類似的。
利用MBR可以進行分佈式處理，它使得遠程調用對象（通過代理）時，該對象可以運行在不同的應用程序域、進程或機器上。此方式適合於調用次數少，而被調用對象運行負荷大，需要負載平衡的情況下，是分佈式處理常規模式。
而MBV可以串行化遠程對象並將其反串行化到客戶端，在客戶端的應用程序域中創建一個遠程對象的副本，這樣就可以象訪問和修改本地對象一樣使用該對象。此方法適用於用來封裝數據，或者對象調用次數多的情況下（因爲會造成網絡負荷）。
4，激活遠程對象策略
Singleton模式：Singleton對象可爲所有客戶端請求共享狀態或資源，但多個客戶端訪問Singleton對象實例時，雖說每個請求都會以一個獨立的工作線程進行工作，但在這些線程訪問和修改對象的實例域時就要考慮線程同步的問題（lock）。
SingleCall模式：運行庫爲每個客戶端請求建立一個新對象來響應，並在完成請求後就釋放對象，在客戶端之間沒有任何可共享的狀態和資源，甚至是被調用的方法間也是如此。也就是說，該對象是無狀態的。在處理很多服務器端的平衡負載請求時，本模式非常有效。
客戶端激活對象：類似於SingleCall對象，每個客戶端都可以激活這個遠程類型的唯一實例，不過不同的是，客戶端激活對象可以持續於多個方法。也就是說，該對象是有狀態的。
5，遠程對象租賃策略
一般來說，消耗資源大、特別是佔用稀有資源的對象，最好採用SingleCall模式，以儘快回收和釋放，此模式不需要關心遠程對象的租賃期。
而Singleton對象和客戶端激活對象爲了保存客戶端的狀態和資源，需要在設計時延續遠程對象租賃的生存期直到斷開關聯爲止（構建和註冊發起者（sponsor））。
6，元數據部署策略
遠程對象的調用是通過代理加遠程通道的工作方式來完成的。當對象通過一個方法調用從服務器返回時，事實上服務器傳遞了一個對象引用（ObjRef），ObjRef保存了構建客戶端代理所需的全部信息，包括類型名、URI、類型層次結構和支持接口（在這些信息當中，類型名起了決定作用，因爲它包含了程序集名），然後客戶端運行庫會反射這個程序集來構建代理。
通過上述原理的分析，知道只有爲客戶端提供服務器的元數據，才能運轉起來。優雅的解決方法是，將每個遠程對象都分成一個接口和一個實現，然後只將接口分佈在客戶機，而將實現放在服務器上。從技術上講，根據需要，在接口程序集中也可以包含抽象基類。另外，可以採用配置文件（事先被持久化到本地或配置庫中）的方法，爲客戶端和服務器定義各自的遠程設置。
如此，服務端業務組件框架作爲一個容器，可動態加載程序集，加載的觸發條件是配置文件是否發生更新，一旦發生更新事件，就重新讀取，根據變化的內容重新構建程序集。從而做到動態部署、即插即用、熱插拔。
4.3.1.2.3 組件框架的實現方法
不管是客戶端還是服務端的業務對象，都是基於組件的方式進行開發。
沿襲Packer for Delphi中的模式，架構提供統一的組件容器，利用.NET的程序集技術、反射機制、Remoting技術等等，實現動態的加載、釋放本地或遠程的業務組件。
組件容器與業務組件、業務組件與業務組件之間，架構都提供標準的接口，利用接口技術來傳遞傳遞消息、對象、數據等；應用系統也可以在這些標準接口基礎之上，擴展成爲自己的接口，以方便開發。
4.3.1.3 持久層
持久層是對關係數據庫持久化操作的數據訪問中間件。
4.3.1.3.1 爲什麼需要持久層
如果直接用SQL來傳遞數據的話，存在許多問題，比如：
¨ 業務改變容易破壞結構化數據的結構
¨ 業務邏輯與數據存儲代碼混在了一起
¨ 隨着應用的增長問題更加明顯
而使用持久層，可以將業務邏輯和數據存儲邏輯隔離開來，業務邏輯操作的是數據的映射而不是實體，在完全消除SQL語句的情況下，支持多記錄的條件查詢、更新、刪除。如此可解決上述問題。
4.3.1.3.2 如何實現持久層
單純地追求絕對的鬆耦合，會帶來性能上的急劇退化。因此，必須權衡利弊，在參考當前流行的持久化模式下，構建適合自己的持久層。
主導思想是，不在運行期動態映射數據庫，而是提供工具由開發者配置和映射數據庫，在運行期通過這些配置信息來構建映射關係，爲業務層提供數據持久化接口。這樣做，雖然少了些靈活性，但性能可以得到保障。
通過工具配置和映射數據庫。方法是自業務到數據，是業務驅動，不是數據驅動。也就是說，通過構建業務對象，來生成虛擬表（數據集）對象，由工具將數據集對象與物理表之間構建出一層映射關係。如此，數據集和物理表的構建可以在規範（結合數據字典）下完成，而業務對象對數據集的操作（查詢、更新、刪除等），也可以通過引擎自動持久化到對映的物理表中。
另外需要提到的是，對於存儲過程的使用將有所限制，即只是在爲優化系統性能的前提下而使用，原則上，它用來做數據的一些操作，比如大批量的數據更新、數據分析等等，而不存放業務邏輯。
目前，基於上述前提條件，有兩種方案可供選擇：
1，將Packer for Delphi中的持久層服務遷移到.NET平臺上
遷移既有的持久層框架，最大的好處是，一套配置工具和配置庫可以同時支持到基於Delphi和.NET的兩種開發平臺，原有的成果可以繼續發揮作用。
這種框架的遷移，碰到的主要技術問題是，如何將MIDAS＋DCOM技術轉換成ADO.NET＋.NET Remoting/Web Service技術。ADO.NET結構示意圖如下：
從上圖可知，ADO.NET框架是非常適合分佈式組件開發的：
l 在應用程序中將數據緩存在本地，以便可以對數據進行處理
l 在層間或從 XML Web 服務對數據進行遠程處理
l 與數據進行動態交互，例如綁定到 Windows 窗體控件或組合並關聯來自多個源的數據
l 對數據執行大量的處理，而不需要與數據源保持打開的連接，從而將該連接釋放給其他客戶端使用
ADO.NET框架與MIDAS框架也有很多相似的地方，比如DataAdapter和TDataSetProvider、DataSet和TClientDataSet，在框架中所在的位置、所起的作用都差不多；服務端和客戶端所傳輸的同樣是數據包，只是格式不同而已，等等。所以說，從MIDAS框架下的持久層遷移到ADO.NET下的持久層，是可行的。
2，開源持久層框架IBatisNet
另外的辦法，就是直接使用第三方開源的持久層框架。經過對當前流行的持久層框架分析和比較下來看，當中比較適合於公司產品的持久層框架，應該是IBatisNet。
IbatisNet算是一個半ORM的框架，或者說Data Map。IBatisNet實際是一個PO與SQL之間的關係映射框架。也就是說，IBatisNet並不會爲開發者在運行期自動生成SQL執行。具體的SQL需要開發者編寫，然後通過映射配置文件，程序將SQL所需的參數傳入，框架將映射好的結果返回。這些與Packer持久層的開發思路較爲相似。
優點：
l 簡單易學
易於學習，易於使用，通過文檔和源代碼，可以比較完全的掌握它的設計思路和實現。
l 靈活
開發人員可以充分利用SQL的強大功能。
l 對數據庫開發的要求低
只要原先通過SQL可以實現的功能，通過IBatisNet幾乎都能夠實現。
l 功能強大
提供了連接管理，緩存支持，線程支持，（分佈式）事物管理，通過配置作關係對象映射等數據訪問層需要解決的問題。提供了DAO支持，並在DAO框架中封裝了ADO.NET，NHibernate和DataMapper。
l 增強系統的可維護性
通過提供DAL層，將業務邏輯和數據訪問邏輯分離，使系統的設計更清晰，更易維護，更易單元測試。SQL和代碼的分離，提高了可維護性。
缺點：
l 半ORM，需要開發人員寫SQL，自動代碼生成工具不完善
l 需要一些XML配置
l 還不是很成熟
l 工程實踐較少，在實際項目中的使用較少。
結論：
從理論上說，由於IBatisNet是一個輕量級的非侵入的框架，使用它的風險會相對低點。他的那些缺點並不是致命的，而且也是有一些解決方案的。由於理念相同，從Packer持久層遷移到IBatisNet相對比遷移到NHibernate要容易得多。所以，在.NET上要選一個第三方開源的持久層框架的話，IBatisNet是一個比較不錯的選擇。
4.3.2 引擎
4.3.2.1 數據集持久化引擎
見上節。
4.3.2.2 工作流引擎
工作流是針對工作中具有固定程序的常規活動而提出的一個概念。通過將工作活動分解成定義良好的任務、角色、規則和過程來進行執行和監控，達到提高生產組織水平和工作效率的目的。工作流技術爲企業更好地實現經營目標提供了先進的手段。
一般說起工作流，其實包含了兩種類型：一種是與行政辦公有關的工作流，以文檔/文件流轉爲主，另一種就是商業（業務）流程，英文中的 Process 更能表達此意思。實現前者目的的平臺產品相對較豐富，如 LotusNotes、Exchange 等，而實現後者的平臺產品似乎相對較少，且功能也不完備。
Microsoft Windows Workflow Foundation(WWF)是一個可擴展框架，用於在.NET平臺上開發工作流解決方案。WWF同時提供了 API 和一些工具，用於開發和執行基於工作流的應用程序。WWF提供單個統一的模型，以便創建跨越多個類別應用程序的端到端解決方案，包括人力工作流和系統工作流。
WWF可構建有狀態的、持久化的、不間斷運行的應用程序。WWF運行時引擎管理工作流的運行，爲工作流的長期運行提供保障，並能抵抗機器的重啓。
WWF爲開發人員提供了一個工作流模型，來描述應用程序所需要的處理過程。通過使用工作流模型所提供的流程控件、狀態管理、事務和同步器，開發人員可以分離應用程序邏輯和業務邏輯，構造一個高層次的抽象，達到提高開發者效率的目的。
WWF可以幫助開發者重用組件。WWF爲開發者提供了一系列的活動——活動是一種包含了工作單元的可配置邏輯結構。這種結構封裝了開發者可能經常性用到的一些部件，這樣就節省了開發者的時間。通過將工作流引擎載入進程，WWF可以使任何應用程序和服務容器運行工作流。運行時服務組件被設計成可插件形式的，這個可使應用程序以最合適的方式來提供它們的服務。
如何將WWF融入到本架構，需要投入資源進行研究，比如：在客戶端如何整合消息驅動型界面、在業務層如何利用數據字典整合數據包、並且如何與消息引擎（消息流）、安全引擎（用戶和權限）進行整合等等。
4.3.2.3 數據動態引擎
數據動態引擎，是將數據庫發生的數據變化，實時表現在客戶端界面上。它在物理佈局上分爲動態刷新服務器、客戶端動態刷新組件、配置工具等三部分，動態刷新服務器提供分佈式負載均衡機制。
4.3.2.3.1 實現機制
4.3.2.3.2 配置工具
配置工具是爲開發者配置數據動態引擎所維護數據集的SQL語句等信息，持久化到配置庫中的，動態刷新服務器依照配置信息來維持其數據集。
4.3.2.3.3 對業務架構設計的建議
經過以往應用系統的開發經驗，建議：數據集的SQL儘可能簡潔、客戶端的表現層和業務層徹底解耦，如此，就能夠使得相關表觸發器的編寫更加簡單、準確，客戶端的代碼編寫也更加容易和麪向對象化；最好是，數據庫結構的設計也要考慮到是否適合數據動態引擎運行等等；總之，希望能夠更好的滿足性能、準確率、刷新量等等功能外的需求。
4.3.2.4 消息引擎
應用系統軟總線包括技術實現上的、也包括設計規範上的。應用系統設計可面向總線進行，設計者只需識別總線，根據總線的規定去設計，將各組件按照總線接口的標準與總線連接而無需單獨爲各組件設計連線。這就簡化了系統的設計，也簡化了系統的結構，使系統易於擴充和更新。
消息引擎是應用系統軟總線的一個關鍵技術，是各組件聯繫的紐帶，在接口技術中扮演着重要的角色。倚靠目前可以利用的技術，我們可以從以下幾處着手來實現它。
4.3.2.4.1 數據包
在總線上傳輸的數據需要統一的標準進行包裝，用以將參數傳遞給框架中的任意對象，即將彼此無關的參數打包成單一和高效的數據封裝包，以簡化系統的設計，這點可以與物流領域中的集箱和散貨做比方，是一個道理。
當交互的對象被某種形式的邊界隔開，數據傳輸的代價就會很高。邊界可以有多種形式：網絡邊界、進程邊界、域邊界（.NET）和存儲邊界（I/O）等等。當開發人員來回設置和獲取數據時，數據傳輸可能帶來性能上的問題。
爲了避免在對象交互期間的多次往返，一種選擇就是在方法中立即傳遞所有參數。數據包就是這樣一些參數的容器，它是一個通用的容器，將按需容納許多參數來滿足任何業務對象。
數據包另一個好處是，可以應對參數集合頻繁改變的情形，只要往返雙方知道怎麼打包和解析即可。
使用ADO.NET的DataSet對象來作爲數據包的容器是可行的方法之一。數據包利用DataSet可以包含任何數據，並傳遞到框架內的每一層。同時，與數據包交互的業務對象不直接和DataSet打交道，而是調用數據包的標準方法（比如GetData（）），爲業務對象提供統一的交互界面。
4.3.2.4.2 數據字典
此處的數據字典不僅僅是指數據庫概念（就數據庫概念將在持久層中專門討論），而是囊括了信息系統內交互的所有信息的元數據。
架構提供專門的配置工具來構建信息系統的數據字典，並持久化到配置庫中供相關標準組件調用。
數據字典的使用，可以規範開發過程，使得系統設計簡單化。首先是參數的規範，開發人員不必自創參數的命名，少了溝通的障礙，也減少了信息的二義性。其次是值的規範，定義了一套公共的代碼表，爲信息系統提供統一的代碼支持。
數據字典的構建，使得表現層、業務層和持久層間的信息交互可以通過數據字典自動匹配，爲自動化處理（工作流等）等應用提供了基礎平臺。
4.3.2.4.3 MessageQueue
利用 Microsoft Windows“消息隊列”，可以通過發送和接收消息方便地與應用系統進行快速可靠的通信。消息處理和消息爲基於服務器的應用程序組件之間的進程間通信提供了強大靈活的機制。同組件間的直接調用相比，它們具有若干優點，其中包括：
1，穩定性
組件失敗對消息的影響程度遠遠小於組件間的直接調用，因爲消息存儲在隊列中並一直留在那裏，直到被適當地處理。消息處理同事務處理相似，因爲消息處理是有保證的。
2，消息優先級
更緊急或更重要的消息可在相對不重要的消息之前接收，因此可以爲關鍵的應用程序保證足夠的響應時間。
3，脫機能力
發送消息時，它們可被髮送到臨時隊列中並一直留在那裏，直到被成功地傳遞。當因任何原因對所需隊列的訪問不可用時，用戶可以繼續執行操作。同時，其他操作可以繼續進行，如同消息已經得到了處理一樣，這是因爲網絡連接恢復時消息傳遞是有保證的。
4，事務性消息處理
將多個相關消息耦合爲單個事務，確保消息按順序傳遞、只傳遞一次並且可以從它們的目標隊列中被成功地檢索。如果出現任何錯誤，將取消整個事務。
5，安全性
MessageQueue 組件基於的消息隊列技術使用 Windows 安全來保護訪問控制、提供審覈並對組件發送和接收的消息進行加密和驗證。
4.3.2.4.4 應用範圍
如何合理地使用MQ技術，是構建可編寫、可部署的應用系統所必須考慮的問題。通過對MQ技術的瞭解，它不是特別適合於數據交互量大、或者不需維持歷史消息的系統，而適合於用戶間的消息通知（必達消息）、協同工作模式下的應用系統。
4.3.2.5 安全引擎
計算機技術安全管理的範圍很廣，可以包括網絡安全性、數據安全性、操作系統安全性以及應用程序安全性等。很多方面的安全性管理大都已經有成熟的產品了，我們只需根據自己需要有選擇性的使用就可達到自己的目的了。本章中有關關涉及‘安全管理’一詞均只針對應用系統中有關對象與數據而言的範圍。
4.3.2.5.1 名稱解釋
主體：即可以嚮應用系統發出應用請求的任何實體，包括各種用戶、其它與本系統有接口的應用程序、非法入侵者。系統必須具有識別主體的能力，接口實際上也是由用戶登記的，故主要問題是校驗用戶身份的合法性，系統應建立用戶鑑別機構以驗證用戶身份。
用戶：用戶就是一個可以獨立訪問計算機系統中的數據或者用數據表示的其它資源的主體，用戶在一般情況下是指人。
權限：權限是對計算機系統中的數據或者用數據表示的其它資源進行訪問的許可。可分爲對象訪問控制和數據訪問控制兩種。
對象訪問控制：用一個二元組來表示：（控制對象，訪問類型）。其中的控制對象表示系統中一切需要進行訪問控制的資源，訪問類型是指對於相應的受控對象的訪問控制，如：讀取、修改、刪除等等。
數據訪問控制：如果不對數據訪問加以控制，系統的安全性是得不到保證的，容易發生數據泄密事件。所以在權限中必須對對象可訪問的數據進行按不同的等級給予加密保護。我們同樣用一個二元組來表示：（控制對象，謂詞）。權限最終可以組合成如下形式：（控制對象，訪問類型，謂詞）。
角色：角色是指一個組織或任務中的工作或位置，它代表了一種資格、權利和責任。
用戶委派：用戶委派是用戶與角色之間的一個二元關係。
權限配置：權限配置是角色與權限之間的一個二元關係。
4.3.2.5.2 總體構思
架構應該能夠做到對對象控制、菜單控制、數據集的控制，將應用系統的安全管理單獨的分離出來，並制定一些整個系統通用的安全準則。應用系統開發者在業務設計時不要過多的考慮程序安全性的問題，而只需遵循系統的安全準則即可，把主要精力花費在系統的業務功能上。
1，基於角色對用戶組進行訪問控制
對一組用戶比對單個用戶進行訪問控制更加合理，用戶組代表了具有相近工作性質的一組用戶的集合，可以委派完成用戶組工作的角色以控制用戶組的權限範圍（當然我們也可以把角色看成是我們系統中一個特定用戶組）。同時支持角色的繼承和多繼承。通過改變用戶的當前角色集就可以改變用戶的權限，而改變某種角色所含的權限時又可以改變一組用戶的權限，基於這種訪問控制方式有3個方面的作用：（1）簡化了權限管理，避免直接在用戶和數據之間進行授權和取消。研究表明，用戶所具有的權限易於發生改變，而某種角色所對應的權限更加穩定；（2）有利於合理劃分職責，用戶只有其所應具有權限，這樣可以避免越權行爲，有關用戶組的關係描述正是對此的支持；（c）防止權力濫用，敏感的工作分配給若干個不同的用戶完成，需要合作的操作序列（工作流）不能由單個用戶完成。
2，支持動態地改變用戶的權限
安全管理考慮了訪問權限不是靜態，而是動態的情況。當應用系統使用工作流時，可通過工作流引擎與安全管理控制核心的接口，動態分配用戶完成當前工作流環節所需的權限。
3，權限的相互關聯
各種權限不是互相獨立而是相互關聯的，而且權限可以感知到其它用戶操作，這可以描述有關協同權限。例如在給數據編輯控件授權只讀權限時，收回用戶對數據插入和刪除權限，該權限允許感知其它用戶的操作，諸如某用戶改變了數據等等。
4，提供方便的授權/取消機制和檢查機制：
只要進行簡單的賦值操作即可完成授權，同時由角色分配規則和主體訪問規則控制這種授權機制的應用。
5，用戶之間的授權關係：
依據角色指派關係，運行系統中的用戶自身可以對角色進行管理，這提供了又一種動態改變用戶權限的手段。通常，角色指派的權力都在系統中具有管理責任的用戶手中。
用戶通過專用客戶端的登陸窗口進入應用系統，專用客戶端依此管理用戶的權限等信息，並根據用戶權限動態生成菜單項和其他的加載項，如工具欄、列表框等等。用戶通過專用客戶端調用具體的組件，而組件（程序集）在用戶的操作過程中動態加載、緩存和管理，即插件的方式。專用客戶端還負責構件（程序集）的下載升級，做到一次安裝永久使用。
4.4 License版權
爲保護應用系統產品的版權，需要在架構中提供版權限制功能，以限制用戶同時登陸數量。
可提供公鑰予客戶對系統進行版權升級，而公鑰是通過開放用戶數、客戶公司名等等信息計算而來。
5 架構層次
如上圖，軟件開發架構開發層次，上層的開發基本將基於下層提供的功能進行開發。
6 設計規範
遵照《.NET設計規範》進行代碼編寫。
7 風險控制
從前文分析，公司將來的產品主要以圖形化交互界面爲主，那麼圖形對象在.NET上的應用，是否能夠支持大批量數據的動態刷新、界面的響應週期等等指標，都需要經過測試才能下結論，這甚至是整個框架是否能夠基於.NET開發平臺之上構建的前提條件。如果拿輕量級的TATUKGIS在壓力測試下也未能達到上述要求的話，那是否中止以.NET開發平臺爲主的框架設計，而轉向以win32（Delphi/C++）開發平臺爲主的框架設計，就應該重新考量的了。
8 技術準備與技術培訓
9 實施方案
技術架構的研發是個迭代、逐步完善的過程，不可能是一蹴而就的工作，同時必須實時響應它所支撐的產品線開發的需求。所以組建專職的技術架構研發組織，可以保障技術架構的研發持續穩固的進行下去，並能切實發揮其效用。
架構的實施，必須得到全體開發人員的配合和理解。因爲應用系統的業務分析、邏輯分層、數據庫設計等等，都是能夠脫離本架構限制，隨意發揮的。在應用系統的設計開發中，哪些可行、哪些不可行，都需要對本架構、.NET平臺技術、分佈式組件開發等技術和方法論，需要有一系列的領悟和使用經驗，並能夠融入到自己的開發當中，才能使業務架構與技術架構完美結合，設計出好的產品。但這些又不是本架構能夠做到的，需要公司相關制度、組織結構、開發團隊的配合
轉載自http://blog.csdn.net/phenixiii/article/month/2007/11
1 引言
1.1 前言
本文將基於目前現有的軟件開發架構（以下簡稱‘架構’）（Packer for Delphi），同時如何合理地引進新技術等問題，進行系統地分析和研究，以指導新架構的研發。
1.2 研發依據
1.2.1 公司發展
1.2.2 開發方式
1.2.3 技術升級
1.2.4 產品線
行業領域軟件需要個性化的服務，如果對應以作坊式的開發方式，將會陷於項目越多，版本也越多，維護成本也隨之上升的局面。
針對行業領域軟件特點，在以產品線爲設計思路的業務架構建設中，需要對應的技術架構來配合完成。
1.3 研發前提
1.3.1 公司產品開發的範圍
1.3.2 軟件開發架構在產品開發中所處的位置
軟件開發架構，是一個承上啓下、集成應用開發領域的通用的各種技術而形成的一整套的開發體系框架，它包括如下的幾個方面：
1、可持續的框架體系：
一個用於明確管理界定各種功能及其關係的框架體系，每個功能點在架構中由於其特性必然有着明確的位置，各種相關技術也由架構來完成其相互的無縫接入。並且通過這種可持續化的特徵，能將技術的、業務的工作管理起來，並持續的發展。
2、技術的集成和整合：
隨着應用領域的拓寬，這些技術會不斷的拓展，包括如：工作流技術，安全技術，消息服務技術，即時通信技術，門戶技術，數據交換技術，全文檢索技術等等。說到集成，就是指除了這些技術本身之外，架構提供對這些技術的整合，將這些技術本身放在整體框架的某個部分和層次。技術的整合不是簡單的拼裝，做得好壞，取決於長期的經驗和技術的積累，否則再好的技術，整合起來往往得到的是最差的東西。
3、更爲細節的規範：
爲了程序的易於理解和維護，便於細化分工，架構將儘可能的減少異化，儘可能的標準化開發過程和代碼格式。這些規範可能會細化到如：打開關閉連接的時機，命名空間的管理，文件名稱的定義，代碼縮進的長度，使用的開發和設計工具等等這樣非常細節化的東西，從而保證一致性。
4、標準、簡單，機械化的開發過程：
追求將開發過程1234化，避免思維的漏洞，將思維上的一種或者幾種有效的開發套路固定爲外在的規範，並且通過一系列的工具將其持久化。
5、最終的追求－－軟件生命週期的管理：
這樣的一個架構，最終追求的是對一個完整的軟件生命週期的管理，不僅僅是開發的過程，還包括規劃，需求，設計，測試等一系列的過程。
總之，架構是爲應用系統的開發，提供一套集成的、適合自身軟件開發過程的技術規範、開發準則、通用組件、輔助工具等等，使得應用系統的開發更加高效、方便、統一，爲軟件大生產的開發提供物質保障。
1.3.3 技術平臺的選型
開始架構研發之前，必須先對架構的基礎－技術平臺，進行選型，否則將是無本之木，一紙空談。
縱觀當前流行的技術平臺，不外乎兩大陣營：J2EE和.NET，以下是針對幾個指標進行的一個評價：
J2EE
.NET
開放性
好
差
應用範圍
Web應用
Web應用或者非web應用
開發工具成本
低廉（開源）
一般（專用）
開發資源成本
高
一般
開發效率
週期長
快速
運行性能
差
一般
運行資源成本
高（捆綁專用服務器）
低（分佈式PC服務器）
部署效率
差
一般
界面豐富與靈活性
差
高
與服務商綁定
高（SUN、IBM）
高（MS）
關於J2EE和.NET之間的討論已經持續很多年了，而且也將繼續爭論下去，孰優孰劣仍然很難下結論。
適用的纔是好的，作爲IT企業，從公司產品的受衆、研發、推行、維護的成本與收入等等上來考慮，自然會得到一個明確的答案。
對於ERP等生產管理系統，系統性能、豐富的表現與交互界面是關鍵的技術要求之一，在非web應用的軟件研發上將主要基於.NET開發平臺。
同時，爲了兼顧效率，可以結合Win32的開發工具（Delphi/C++）開發部分實時性要求很高的應用系統，對於這點，.NET自身可以很好的與Win32進行整合。
1.4 系統名稱
1.5 中期計劃
1.6 資源計劃
2 參考文獻
3 功能分析
通過分析歸納，技術架構的開發，只要針對如下幾大項的功能點進行研發，基本上可以支持目前所遇到的大部分技術需求：
項目
內容
支持雙語
雙語是指開發出來的應用系統，應該在表現層上，只要根據用戶的簡單選擇，就能提供中文、英文之一種語言顯示效果。
提供對雙語的技術支持，方便開發人員通過配置工具配置應用系統相關的屬性（提示信息、按鈕標籤、數據標籤等等），而在代碼設計中只需對相關組件進行簡單的定義，即可實現此功能。
數據字典
數據字典是對應用系統用到的所有數據項和結構的定義，以確保開發人員使用統一的數據定義。
本數據字典不僅包含數據庫數據字典部分內容，而且進行了擴充，比如表字段的雙語標籤等的屬性定義，再外延出去的話，還包括公共代碼的統一管理等。
數據字典是技術架構與系統業務分析的基礎，比如數據動態、持久層中的自動構建數據集、自動操作數據庫等等功能，都要用到數據字典。
持久層
對象化存儲就是將數據庫中的數據在對象中實例化，當修改這個對象的屬性時，數據庫中的相應字段也會隨之改變，通常叫做持久層。
持久層應該提供事務管理、鎖機制、緩存機制。
數據動態
將應用系統中發生的數據變化，實時通知需要獲知變更的組件中，使得數據在需要同步的組件中保持一致性。
安全管理
對應用系統的登陸用戶進行校驗與權限上的管理，包括菜單、按鈕、記錄的增刪減等等。
支持工作流模式。
日誌管理
對應用系統中敏感數據的更新，必須持久化，記錄由何人、何時、何地（IP）和數據的新舊變更，以便跟蹤。
應用系統中，由數據庫、中間層、客戶端所產生的陷阱信息都歸到日誌管理中。
日誌按照日誌類型、輕重程度、緩急程度等分級（可以由用戶自定義），並設置日誌發送的目的地：本地、數據庫、監控中心、手機等等。
用戶界面框架
總結表現層常用的界面模式，歸整爲統一的組件或模板，方便開發，統一應用系統的界面風格。
客戶端組件框架
客戶端的開發，關注於主程序、界面組件、工作間組件等。
主程序以EXE形式實現，而其餘組件以DLL形式實現，主程序通過響應菜單來驅動組件運行。
必須規範主程序與組件間的接口。
服務端組件框架
服務端的開發，關注於主程序和業務組件。
主程序以EXE形式實現，而其餘組件以DLL形式實現，主程序通過響應客戶端來驅動組件運行。
必須規範主程序與組件間的接口。
通用報表
用戶可以自定義報表，用戶自定義的報表模板可按功能（樹狀層次）保存供以後或其他用戶重複使用。
報表不僅要輸出到打印機，而且應該能輸出到Text、RTF、PDF、Excel、Word、HTML等等文檔格式，並能夠通過Email發送出去。
報表可以人爲增加、刪除列表項，人爲將列表項重新排列、進一步搜索列表項等等。
工作流
工作流是針對工作中具有固定程序的常規活動而提出的一個概念。
通過將工作活動分解成定義良好的任務、角色、規則和過程來進行執行和監控，達到提高生產組織水平和工作效率的目的。工作流技術爲企業更好地實現經營目標提供了先進的手段。
協同性
協同性在物流系統的管理上非常重要，很多作業需要多角色的配合來完成，因此在應用系統的實現上，需要考慮協同性問題，以方便用戶工作。
各部門、各人員，以及企業和外部資源之間可以共享信息、實現即時溝通和協同運作，大大提升運作效率，減少企業管理和運營的成本。
應用系統發佈策略
對應用系統的發佈採取許可授權（license）的方法，可避免應用系統被盜用或者超範圍使用，以保護公司的知識產權。
應用系統的升級，用戶應該少受到影響，並且儘可能方便。
負載均衡
應用服務器應該具有可擴展性，即達到分佈式。
在多個應用服務器提供服務的情況下，客戶端連接服務器的策略，應該達到均衡連接，而一旦某臺服務器當機時，客戶端可以自動嘗試連接其他服務器。
4 總體框架
4.1 分佈式C/S/S框架
非web應用系統，將在基於分佈式的C/S/S框架下進行開發。
分佈式C/S/S框架和傳統的C/S框架之不同點，在於客戶端和數據庫之間加入了應用服務器這一中間層。
4.1.1 優勢
使用分佈式C/S/S框架具有如下的優勢：
1， 減輕處理器的負荷
主要是爲了減輕數據庫的負荷，由相對價廉的應用服務器來分攤其運算負荷。
2， 可伸縮性的要求
如果業務設計正確，業務邏輯就能夠被複制和分佈到幾個負載均衡的應用服務器上，如果用戶數量增加，則可以添加更多的服務器以滿足需求。
3， 部署和可維護性的要求
分佈式架構下的客戶機，可以做到在啓動時通過應用服務器進行自我更新；另外，添加功能模塊也更容易些。
4， 稀有資源的共享
應用服務器將稀有資源（比如數據庫連接）放在緩衝池中，這樣可以在多個客戶機上共享它們。
4.1.2 負載平衡
分佈式計算最大的問題是如何做到負載平衡。基於計算中一個簡單的事實：調用不同進程上對象的方法要比調用進程內對象的方法慢數百倍，如果將對象移到網絡中的另一臺機器上，這種方法調用又會慢數十倍。
所以，在應用系統的業務設計（技術架構與業務架構的關聯）上須從以下幾點考慮：
1， 客戶機上不一定是絕對和業務邏輯無關，數據庫也絕對不是不能處理業務邏輯，而應該遵循‘相關內容本地化’的原則，靈活處理；
2， 遠程對象應該提供粗粒度的接口，以減少在網絡中的信息交互量；
3， 優先選用無狀態的對象，以提高系統可擴展性，爲多應用服務器的負載平衡機制提供條件。
只有在應用系統的業務設計上，做到了上述幾點要求，那麼整個系統的性能就可以得到保障，否則用什麼架構都是徒勞無益的。
另外，針對多應用服務器的負載平衡，本架構在客戶端的登陸處理方式上，提供一套機制，使得客戶端啓動時，自動登陸到負載最輕的一個應用服務器上。
4.2 基於組件開發
基於組件的開發是個方法論框架，對於指導我們如何建設：開發體系結構、技術體系結構、應用體系結構和項目管理系統結構，都有很大的幫助意義。
採用這種方法，開發生命週期中的所有問題和階段，包括需求分析、體系結構、設計、構建、測試、部署、支持技術基礎設施和項目管理，都將是基於組件進行。
4.2.1 基於組件開發的益處
1， 控制開發複雜性
可以提供劃分業務領域的極佳方法，開發過程是通過組件組裝大規模系統而不是構建這些系統。
2， 改變應用系統的本質
按照用戶的視點開發組件並組裝系統，從而帶來市場推銷和購買軟件解決方案的新方式。
3， 實現部件的自治開發
應用系統以一組準自治部署單元構成，從而支持新的和富有挑戰性的高層併發開發、測試和部署。爲此將改變開發模式和組織結構，由業務領域和專業領域來劃分產生基於接口協同的自治開發小組（技術架構與組織架構的關聯），而項目的運作則是依照訂單來定購這些組件進行組裝。
4， 控制部署複雜性
特別體現在系統的演化（變更）過程中，因爲系統的修改和更正只會影響一個組件。
5， 縮短產品投放市場所需的時間
成熟的基於組件的開發會大大縮短軟件的開發週期，基於組件的開發很容易通過現有的組件組裝新的系統。
4.2.2 基於組件開發的層次
1，分佈式組件
從粒度角度看，分佈式組件是最小的組件，具有可通過網絡尋址的接口，通常採用商品化的組件實現技術（例如CORBA、EJB、.NET Remoting或DCOM等）實現。
這種設計模式的目標是支持大規模分佈式系統的高生產率開發。
定義分佈式組件的方式，使概念設計人員和開發人員只需要關注描述接口、編寫業務邏輯、定義到持久存儲的映射以及調用其他分佈式組件的服務，從而降低功能開發人員的工作複雜度。
2，業務組件
業務組件是自治業務概念（實體或過程）的軟件實現。業務組件包含把給定業務概念表示、實現和部署爲更大分佈式信息系統的自治、可重用要素所需的全部軟件工件。
具有各種體系結構原則和概念的業務組件可以用任何語言實現，雖然當前的商品化的建模工具和組件實現技術並不直接支持業務組件概念，但業務組件是一種極爲有力的邏輯概念，可以用來降低大規模開發的複雜性，獨立於下層開發環境的支持級別。我們可以在不同程度上採用業務組件概念，都會帶來可觀的開發效益。
業務組件開始是需求階段的一種單個結構，到了部署、配置和維護階段，仍然是同一個單元。從這個意義上說，業務組件概念涵蓋了整個開發生命週期。
3，業務組件系統
描述業務組件之間的協同關係，是對業務組件的組裝，提供了針對某個業務問題的解決方案。
業務組件組裝作爲開發、測試、部署和發佈單元是很有用的。不僅如此，業務組件組裝還可以看作是一種進化或維護單元，即通過一個單一操作，就可以用新版本替換整個業務組件組裝。
4.2.3 基於組件開發的開發過程
基於組件的開發過程有以下10個黃金特徵：
1， 以組件爲核心
在整個開發過程，以及所有的體系結構考慮和業務組件方法的所有其他問題，都圍繞不同級別粒度的組件展開。
2， 以體系結構爲中心
在整個開發生命週期都採用系統結構視點推動系統的進化。
3， 關注自治
在每個開發生命週期階段，都必須在適當的層次上採取關注自治性的步驟。
4， 向協同發展
在關注自治的同時，實現高水平的協同。一方面，要對單個業務組件進行自治的分析、設計、實現和測試，另一方面又需要保持系統作爲一個整體的完整性，保持這種不同自治單元之間的各種潛在協同的完整性。
5， 迭代特性
開發過程通過自治地實現和進化單個組件，支持具有明顯迭代和漸進特徵的過程。爲了支持這種過程具有成本效益，開發環境理念必須支持整個生命週期內的快速迭代。
6， 高水平的併發開發
前面的特徵支持獨立團隊彼此互相獨立和併發地設計、開發和測試系統部件，同時仍然保持整個系統的完整性。這是快速開發的一個基本要素，並直接支持經濟地完成軟件製造的目標。
7， 持續集成
功能開發人員應該能夠持續地開發系統部件，並立即得到有關係統功能和行爲的系統級反饋，同時又要把注意力集中在構建系統的功能上，而不是技術細節上。
8， 支持風險管理驅動的開發
倡導對項目狀況進行立即反饋，以便不斷驗證和確認各種設計和實現決策；倡導小型、快速迭代，採用合適的工具和過程管理。
9， 突出強調重用
重用要運用於生命週期從需求開始的所有階段。
10， 把組件開發作爲產品開發
業務組件是在儘可能多的地方重用的產品，好的產品開發的突出特徵，是十分關注質量、文檔和支持。交付的產品應該具有“活的文檔”的特徵，即總是保持最新狀態的文檔。
4.3 基於組件開發的分層框架
在分佈式C/S/S框架下，可以實現基於組件的分層設計。
4.3.1 分層
層（layer）：層是對架構的橫向劃分，對模型中同一抽象層次上的包進行分組的一種特定方式。通過分層，使系統以更鬆散的方式耦合，從而更易於維護。分層是對系統邏輯上的分層，在實際應用中將根據系統效率、負載平衡等等實際情況，變通、權衡地實現具體的應用。
我們將應用系統的設計劃分爲：表現層、業務層、持久層等，在這些層上分別構建相應的組件框架，以利於方便和規範應用系統實現分層框架。
表現層包含‘客戶端界面組件框架’，業務層包含‘客戶端業務組件框架’、‘服務端業務組件框架’，持久層包含‘數據集持久化引擎’；而‘工作流引擎’、‘數據動態引擎’、‘消息引擎’、‘安全引擎’等是橫跨表現層、業務層和持久層。
以下將按照分層和引擎分別表述。
4.3.1.1 表現層
表現層是用戶和應用系統進行交互的接口。它輔助用戶輸入，提供各種提示和幫助、響應用戶操作所觸發的各種事件、限制用戶的輸入、處理一些特殊的操作等等。
在表現層上，需要提供一整套的支撐模塊和組件框架，以統一界面風格、設計模式。
4.3.1.1.1 分類描述
1， 窗體模版
通過項目和產品實踐中不斷的積累，逐步歸納整理出一套具有自身特色的標準模版：主窗體、多窗體、對話框窗體、數據處理窗體、查詢打印窗體等等。
2， 客戶化定製
用戶可以自定義界面風格、自定義操作風格、自定義數據顯示與輸出模式。比如：報表可以由用戶自定義，而且可以將自定義模板持久化到本地或配置庫中供其他用戶使用等等。
這些定製化的功能，需要第三方界面控件的配合來完成，必要得話，要對這些控件進行二次開發。
3， 導向型界面框架
有些界面之間存在明確的處理順序，用戶可以選擇‘上一步’、‘下一步’或者‘結束’，界面之間的跳轉是由用戶觸發的，用戶的操作流程可以用一張流程（導航）圖來描述，導航圖上每一個節點就是一個用戶界面。爲此，可以通過這樣一個流程控制器，以隔離界面與業務邏輯，對流程中的界面進行管理，提供狀態保存和傳遞的機制。
本框架是工作流引擎在客戶端上一個獨立的外延子項，核心組件爲通用的流程控制器和狀態機，狀態信息的持久化在本地，以便恢復導航圖中每個節點的當時狀態。另外，利用這個組件，也可以在系統正常退出時保存界面狀態，以便重啓客戶端時，將界面恢復到當初退出時的狀態。
導向型界面是解決單個用戶的多步操作行爲，如果每步的界面是由不同的用戶來操作的話，就得靠消息驅動來提供作業的導航了。
4， 消息驅動型界面框架
一個任務可以由多位用戶協作完成，當前一個用戶完成自身的工作後，可以將此任務傳遞到下道工序的用戶，任務通過流程控制器進行流轉。消息驅動型的界面，使得用戶的操作是由消息來推動，任務是分派來的而不是主動去找的。爲隔離界面與業務邏輯，通過流程控制器對消息驅動型界面進行管理，提供狀態保存和傳遞的機制。
本框架是工作流引擎在客戶端上的一個關鍵子項，核心組件爲通用的流程控制器和狀態機，狀態信息的持久化在配置庫，以便恢復導航圖中每個節點的當時狀態。
本框架的具體實際機制，將由最終選用的工作流引擎來定，將在下面的專題章節中單獨討論。
5， 整合第三方表單控件
第三方表單控件，是相對圖形化控件而言，分普通窗體控件和數據感知控件。
第三方表單控件的引進，必須遵照少而精的策略，如果開發工具本身自帶的控件已能滿足開發需求，那麼就不要再使用相同功能的第三方控件，花哨實無必要。
目前可以嘗試引進的第三方界面控件，大致如下:
ComponentOne Studio for.NET；
Developer ExpressComponent for .NET；
6， 整合第三方圖形控件
我們所開發的產品，80％的界面將是圖形化交互模式，不僅僅要畫出無數各種形狀和顏色的小圖形，而且這些圖形也是一個個對象，需要隨時根據動態刷新數據變換顏色、形狀、位置等等，另外，它又是可以與用戶進行交互的，可接受鼠標的點擊、選擇、聚焦、拖放、獲取屬性等等。
在現有產品中，我們已經成功地使用了第三方的控件： TATUK GIS for VCL，積累了不少的開發經驗。在.NET開發平臺上，也有該產品線：TATUK GIS for .NET，所以，相信目前的產品可以平滑地遷移到新的技術平臺上。
7， 整合第三方報表控件
用戶可以自定義報表，人爲增加、刪除列表項，人爲將列表項重新排列、進一步搜索列表項等等，用戶自定義的報表模板可按功能（樹狀層次）保存供以後或其他用戶重複使用。
報表不僅要輸出到打印機，而且應該能輸出到Text、RTF、PDF、Excel、Word、HTML等等格式文件，並能夠通過Email發送出去。
一些第三方的表單控件，可以將數據列表輸出到打印機和各種格式的文件中，此處專門討論專業報表控件，除了VS2005自帶的Crystal Reports（水晶報表）外，目前可以嘗試引進的第三方報表控件有：
ActiveReports for .NET；
Grid++Report（COM組件）；
8， 動態菜單
沿襲Packer for Delphi中的模式，應用系統的菜單可以通過配置工具定義的內容進行動態構建。
當菜單項與客戶端業務組件進行關聯後，業務組件就可以被自動調用（通過客戶端業務組件框架）；當業務組件與安全引擎進行關聯後，菜單項的Enabled和Visible屬性都能被自動設置。
動態菜單的設計，將繼承自VS2005自帶的菜單控件，分標準菜單和樹狀菜單兩種。
4.3.1.1.2 智能客戶端
智能客戶端（Smart Client）是微軟爲開發表現層而提供的一套‘集成式桌面框架’，聲稱將淘汰掉基於瀏覽器的開發模式，雖說是針對web應用，但將客戶端開發迴歸到桌面，保持豐富的表現性和互操作性，是我們所需要的。
智能客戶端包含了一些基本服務：上下文服務、部署服務、安全服務、集成服務等等。
4.3.1.2 業務層
業務邏輯層，有人把這一層叫做業務基礎平臺，或者叫做領域框架層。這一層是針對某一行業或特定類型應用的通用的軟件實現，具有業務的通用性。它可以更高程度地實現軟件的複用，同時又支持用戶的個性化需求的實現，能夠快速地開發用戶所需要的應用系統。而基於組件的開發方式是爲達到此目的的唯一實現過程。
如何構建業務層，必須從服務、組件、對象三個層次分析問題，服務包含了組件、組件包含了對象，對象在組件中被複用，組件在服務中被複用，而對象、組件、服務的關係必須是鬆耦合的。爲做到這點，按照面向對象的方法，核心功能一般被實現爲一組以特定方式交互的抽象的類，在導出具體的應用時，這些抽象的類由特定的具體子類替換。而從組件和服務的觀點來說，這些抽象類就是接口。總之，接口是構建業務層的關鍵點。
爲了實現業務層，我們抽象出一層來通過接口協調其中的對象、組件、服務，這就是業務組件容器，它是組件運行時所處的空間，負責組件的生命週期管理以及組件運行需要的上下文管理。當用戶希望執行一個業務的時候，我們可以要求容器創建這個業務對象，業務容器可以交給我們一個業務對象的代理，隱藏真實的對象的位置。實際的執行過程可能是分佈式的，容器爲我們管理業務對象的事務性，保存業務執行的進度，必要的時候暫停業務，條件成熟後再重新開始，業務完成以後將對象銷燬……這些我們都不必關心，由容器爲我們做。
按照分佈式系統的物理實現，將業務層中的組件分爲：客戶端業務組件、服務端業務組件，它們都由業務組件容器統一管理和調配。客戶端業務組件框架是客戶端業務組件的容器，提供與客戶端界面組件和服務端業務組件的標準接口；服務端業務組件框架是服務端業務組件的容器，提供與客戶端業務組件和持久層引擎的標準接口。
4.3.1.2.1 客戶端業務組件框架
沿襲Packer for Delphi中的模式，基於DLL的插件框架將被遷移到基於程序集的插件框架。它們沒有本質的區別，只是.NET的程序集爲組件開發提供了更方便的開發環境和調試環境，同樣也方便了組件的部署。
組件框架爲應用系統開發提供標準的接口，當應用系統需要創建某個業務對象時，組件框架利用.NET的反射機制，通過接口動態加載相關的程序集並啓動這個業務對象。缺省情況下，組件框架會傳遞給這個組件當前應用系統的用戶權限等等信息；同樣，調用方和被調的組件之間，也可以通過接口傳遞消息、數據、對象等。
程序集可以實現動態插拔，只需更改配置信息（事先被持久化到本地或配置庫中）和XCOPY相應的組件，就可以無須編譯直接定製出一個特定的應用系統。
客戶端業務組件與服務端業務組件之間的聯繫，是採取請求服務和提供服務的方式處理的。
4.3.1.2.2 服務端業務組件框架
服務端業務組件通過遠程組件容器供客戶端調用。.NET框架有兩種組件容器供遠程調用：XMLWeb服務和.NET Remoting。
.NET Remoting 和JAVA的RMI一樣，允許開發人員將網絡中獨立機器上的組件（程序集）連接起來構成應用程序，前提是假設是在一個同構環境中，假定.NET應用位於通信通道的兩端。
XMLWeb服務可以使Web站點和應用程序之間象組件（程序集）那樣互相作用，跟所有的組件（程序集）一樣，Web服務也是通過一些方法來提供它的功能。與.NET Remoting不同的是，Web服務被設計爲可以在異構環境中工作。
XMLWeb服務和.NET Remoting有許多相似之處，它們共享許多諸如SOAP和WSDL等組件（程序集），而且ASP.NET可以駐留遠程對象，並通過HTTP通道使用SOAP串行化技術來提供這些對象，使得遠程對象看起來就象是個Web服務。但是，它們是根本不同的技術，.NET Remoting使用串行化機制來保持CTS（Common Type System，即.NET通用類型系統）類型的可靠性，而Web服務使用串行化機制來保持XML Schema（XML文檔類型系統）類型的可靠性。正因爲如此，當知道客戶端僅是.NET客戶端時，使用.NET Remoting比較合適，而如果還需要支撐很多類型的客戶端平臺時，Web服務會更適合這項工作。
一般而言，信息系統對外的接口，或者信息系統內的子系統之間接口，可以採取XMLWeb服務的方式（即SOA架構）；而子系統內則採取.NET Remoting方式。
1，效率分析策略
從系統效率考慮，.NET Remoting提供了HTTP和TCP兩種通道、SOAP和二進制兩種傳輸格式，可互相組合使用，而且還可以在一個服務器上同時註冊一個HTTP通道和一個TCP通道，以滿足不同的需要。
TCP通道利用TCP/IP網絡協議提供了連接性，默認情況下，信息被轉換成二進制格式，二進制有效負荷相對而言比較小，因此TCP通道與HTTP通道相比執行起來更容易。不過，TCP通道需要在服務器上建立唯一的網絡端口，這點以及他專門的二進制格式，在傳送方法調用時，要通過防火牆會比較困難。不過，在一個封閉的網絡環境（也就是說在防火牆後面）中，要獲得性能更好的連接性，首選TCP通道。
HTTP通道利用HTTP網絡協議提供連接性，在Web服務器和Web瀏覽器間也使用HTTP協議。默認情況下，信息被轉換成SOAP格式，由於SOAP基於XML語言，有效負荷會更大一些，因此HTTP通道比TCP通道執行起來要慢一些。但從另一個角度來說，也更要靈活一些。例如，IIS可以作爲遠程對象的主機，並在HTTP通道中提供這些遠程對象。因爲IIS是在端口80（所有Web服務器的默認端口號）進行監聽，不需要再打開一個新的端口來提供對遠程對象的連接。而且，防火牆的通常配置容許80端口的請求，因此如果要更順利地通過防火牆，首選HTTP通道。
爲了將TCP通道的速度和HTTP通道的靈活性進行折中，可以使用帶有二進制格式化的HTTTP通道。這樣可以爲IIS駐留遠程對象提供靈活性，還可以使之很容易地通過防火牆。不過，TCP通道本身比HTTP通道更有效，因此，TCP通道/二進制格式化的組合還是要比HTTP通道/二進制格式化的組合更快一些。
另外，.NETRemoting的調用機制有同步和異步之分，當客戶端需要及時響應用戶操作的情況下，可以選用異步方式（委託）調用遠程對象。
2，駐留遠程對象策略
上述提到的IIS駐留遠程對象方式是一種，另外還可以駐留在Windows服務中。
Windows服務可以在機器重啓時自動啓動，並且可以使用一個特定的用戶帳號執行，也不會干擾本機上的其他用戶，這些特點都使得Windows服務非常適合於駐留遠程對象。
3，編組遠程對象策略
.NET以兩種不同的方式編組對象：通過值編組（MBV）和通過引用編組（MBR），從概念上講，這些編組技術與通過值和通過引用傳送參數的表示法是類似的。
利用MBR可以進行分佈式處理，它使得遠程調用對象（通過代理）時，該對象可以運行在不同的應用程序域、進程或機器上。此方式適合於調用次數少，而被調用對象運行負荷大，需要負載平衡的情況下，是分佈式處理常規模式。
而MBV可以串行化遠程對象並將其反串行化到客戶端，在客戶端的應用程序域中創建一個遠程對象的副本，這樣就可以象訪問和修改本地對象一樣使用該對象。此方法適用於用來封裝數據，或者對象調用次數多的情況下（因爲會造成網絡負荷）。
4，激活遠程對象策略
Singleton模式：Singleton對象可爲所有客戶端請求共享狀態或資源，但多個客戶端訪問Singleton對象實例時，雖說每個請求都會以一個獨立的工作線程進行工作，但在這些線程訪問和修改對象的實例域時就要考慮線程同步的問題（lock）。
SingleCall模式：運行庫爲每個客戶端請求建立一個新對象來響應，並在完成請求後就釋放對象，在客戶端之間沒有任何可共享的狀態和資源，甚至是被調用的方法間也是如此。也就是說，該對象是無狀態的。在處理很多服務器端的平衡負載請求時，本模式非常有效。
客戶端激活對象：類似於SingleCall對象，每個客戶端都可以激活這個遠程類型的唯一實例，不過不同的是，客戶端激活對象可以持續於多個方法。也就是說，該對象是有狀態的。
5，遠程對象租賃策略
一般來說，消耗資源大、特別是佔用稀有資源的對象，最好採用SingleCall模式，以儘快回收和釋放，此模式不需要關心遠程對象的租賃期。
而Singleton對象和客戶端激活對象爲了保存客戶端的狀態和資源，需要在設計時延續遠程對象租賃的生存期直到斷開關聯爲止（構建和註冊發起者（sponsor））。
6，元數據部署策略
遠程對象的調用是通過代理加遠程通道的工作方式來完成的。當對象通過一個方法調用從服務器返回時，事實上服務器傳遞了一個對象引用（ObjRef），ObjRef保存了構建客戶端代理所需的全部信息，包括類型名、URI、類型層次結構和支持接口（在這些信息當中，類型名起了決定作用，因爲它包含了程序集名），然後客戶端運行庫會反射這個程序集來構建代理。
通過上述原理的分析，知道只有爲客戶端提供服務器的元數據，才能運轉起來。優雅的解決方法是，將每個遠程對象都分成一個接口和一個實現，然後只將接口分佈在客戶機，而將實現放在服務器上。從技術上講，根據需要，在接口程序集中也可以包含抽象基類。另外，可以採用配置文件（事先被持久化到本地或配置庫中）的方法，爲客戶端和服務器定義各自的遠程設置。
如此，服務端業務組件框架作爲一個容器，可動態加載程序集，加載的觸發條件是配置文件是否發生更新，一旦發生更新事件，就重新讀取，根據變化的內容重新構建程序集。從而做到動態部署、即插即用、熱插拔。
4.3.1.2.3 組件框架的實現方法
不管是客戶端還是服務端的業務對象，都是基於組件的方式進行開發。
沿襲Packer for Delphi中的模式，架構提供統一的組件容器，利用.NET的程序集技術、反射機制、Remoting技術等等，實現動態的加載、釋放本地或遠程的業務組件。
組件容器與業務組件、業務組件與業務組件之間，架構都提供標準的接口，利用接口技術來傳遞傳遞消息、對象、數據等；應用系統也可以在這些標準接口基礎之上，擴展成爲自己的接口，以方便開發。
4.3.1.3 持久層
持久層是對關係數據庫持久化操作的數據訪問中間件。
4.3.1.3.1 爲什麼需要持久層
如果直接用SQL來傳遞數據的話，存在許多問題，比如：
¨ 業務改變容易破壞結構化數據的結構
¨ 業務邏輯與數據存儲代碼混在了一起
¨ 隨着應用的增長問題更加明顯
而使用持久層，可以將業務邏輯和數據存儲邏輯隔離開來，業務邏輯操作的是數據的映射而不是實體，在完全消除SQL語句的情況下，支持多記錄的條件查詢、更新、刪除。如此可解決上述問題。
4.3.1.3.2 如何實現持久層
單純地追求絕對的鬆耦合，會帶來性能上的急劇退化。因此，必須權衡利弊，在參考當前流行的持久化模式下，構建適合自己的持久層。
主導思想是，不在運行期動態映射數據庫，而是提供工具由開發者配置和映射數據庫，在運行期通過這些配置信息來構建映射關係，爲業務層提供數據持久化接口。這樣做，雖然少了些靈活性，但性能可以得到保障。
通過工具配置和映射數據庫。方法是自業務到數據，是業務驅動，不是數據驅動。也就是說，通過構建業務對象，來生成虛擬表（數據集）對象，由工具將數據集對象與物理表之間構建出一層映射關係。如此，數據集和物理表的構建可以在規範（結合數據字典）下完成，而業務對象對數據集的操作（查詢、更新、刪除等），也可以通過引擎自動持久化到對映的物理表中。
另外需要提到的是，對於存儲過程的使用將有所限制，即只是在爲優化系統性能的前提下而使用，原則上，它用來做數據的一些操作，比如大批量的數據更新、數據分析等等，而不存放業務邏輯。
目前，基於上述前提條件，有兩種方案可供選擇：
1，將Packer for Delphi中的持久層服務遷移到.NET平臺上
遷移既有的持久層框架，最大的好處是，一套配置工具和配置庫可以同時支持到基於Delphi和.NET的兩種開發平臺，原有的成果可以繼續發揮作用。
這種框架的遷移，碰到的主要技術問題是，如何將MIDAS＋DCOM技術轉換成ADO.NET＋.NET Remoting/Web Service技術。ADO.NET結構示意圖如下：
從上圖可知，ADO.NET框架是非常適合分佈式組件開發的：
l 在應用程序中將數據緩存在本地，以便可以對數據進行處理
l 在層間或從 XML Web 服務對數據進行遠程處理
l 與數據進行動態交互，例如綁定到 Windows 窗體控件或組合並關聯來自多個源的數據
l 對數據執行大量的處理，而不需要與數據源保持打開的連接，從而將該連接釋放給其他客戶端使用
ADO.NET框架與MIDAS框架也有很多相似的地方，比如DataAdapter和TDataSetProvider、DataSet和TClientDataSet，在框架中所在的位置、所起的作用都差不多；服務端和客戶端所傳輸的同樣是數據包，只是格式不同而已，等等。所以說，從MIDAS框架下的持久層遷移到ADO.NET下的持久層，是可行的。
2，開源持久層框架IBatisNet
另外的辦法，就是直接使用第三方開源的持久層框架。經過對當前流行的持久層框架分析和比較下來看，當中比較適合於公司產品的持久層框架，應該是IBatisNet。
IbatisNet算是一個半ORM的框架，或者說Data Map。IBatisNet實際是一個PO與SQL之間的關係映射框架。也就是說，IBatisNet並不會爲開發者在運行期自動生成SQL執行。具體的SQL需要開發者編寫，然後通過映射配置文件，程序將SQL所需的參數傳入，框架將映射好的結果返回。這些與Packer持久層的開發思路較爲相似。
優點：
l 簡單易學
易於學習，易於使用，通過文檔和源代碼，可以比較完全的掌握它的設計思路和實現。
l 靈活
開發人員可以充分利用SQL的強大功能。
l 對數據庫開發的要求低
只要原先通過SQL可以實現的功能，通過IBatisNet幾乎都能夠實現。
l 功能強大
提供了連接管理，緩存支持，線程支持，（分佈式）事物管理，通過配置作關係對象映射等數據訪問層需要解決的問題。提供了DAO支持，並在DAO框架中封裝了ADO.NET，NHibernate和DataMapper。
l 增強系統的可維護性
通過提供DAL層，將業務邏輯和數據訪問邏輯分離，使系統的設計更清晰，更易維護，更易單元測試。SQL和代碼的分離，提高了可維護性。
缺點：
l 半ORM，需要開發人員寫SQL，自動代碼生成工具不完善
l 需要一些XML配置
l 還不是很成熟
l 工程實踐較少，在實際項目中的使用較少。
結論：
從理論上說，由於IBatisNet是一個輕量級的非侵入的框架，使用它的風險會相對低點。他的那些缺點並不是致命的，而且也是有一些解決方案的。由於理念相同，從Packer持久層遷移到IBatisNet相對比遷移到NHibernate要容易得多。所以，在.NET上要選一個第三方開源的持久層框架的話，IBatisNet是一個比較不錯的選擇。
4.3.2 引擎
4.3.2.1 數據集持久化引擎
見上節。
4.3.2.2 工作流引擎
工作流是針對工作中具有固定程序的常規活動而提出的一個概念。通過將工作活動分解成定義良好的任務、角色、規則和過程來進行執行和監控，達到提高生產組織水平和工作效率的目的。工作流技術爲企業更好地實現經營目標提供了先進的手段。
一般說起工作流，其實包含了兩種類型：一種是與行政辦公有關的工作流，以文檔/文件流轉爲主，另一種就是商業（業務）流程，英文中的 Process 更能表達此意思。實現前者目的的平臺產品相對較豐富，如 LotusNotes、Exchange 等，而實現後者的平臺產品似乎相對較少，且功能也不完備。
Microsoft Windows Workflow Foundation(WWF)是一個可擴展框架，用於在.NET平臺上開發工作流解決方案。WWF同時提供了 API 和一些工具，用於開發和執行基於工作流的應用程序。WWF提供單個統一的模型，以便創建跨越多個類別應用程序的端到端解決方案，包括人力工作流和系統工作流。
WWF可構建有狀態的、持久化的、不間斷運行的應用程序。WWF運行時引擎管理工作流的運行，爲工作流的長期運行提供保障，並能抵抗機器的重啓。
WWF爲開發人員提供了一個工作流模型，來描述應用程序所需要的處理過程。通過使用工作流模型所提供的流程控件、狀態管理、事務和同步器，開發人員可以分離應用程序邏輯和業務邏輯，構造一個高層次的抽象，達到提高開發者效率的目的。
WWF可以幫助開發者重用組件。WWF爲開發者提供了一系列的活動——活動是一種包含了工作單元的可配置邏輯結構。這種結構封裝了開發者可能經常性用到的一些部件，這樣就節省了開發者的時間。通過將工作流引擎載入進程，WWF可以使任何應用程序和服務容器運行工作流。運行時服務組件被設計成可插件形式的，這個可使應用程序以最合適的方式來提供它們的服務。
如何將WWF融入到本架構，需要投入資源進行研究，比如：在客戶端如何整合消息驅動型界面、在業務層如何利用數據字典整合數據包、並且如何與消息引擎（消息流）、安全引擎（用戶和權限）進行整合等等。
4.3.2.3 數據動態引擎
數據動態引擎，是將數據庫發生的數據變化，實時表現在客戶端界面上。它在物理佈局上分爲動態刷新服務器、客戶端動態刷新組件、配置工具等三部分，動態刷新服務器提供分佈式負載均衡機制。
4.3.2.3.1 實現機制
4.3.2.3.2 配置工具
配置工具是爲開發者配置數據動態引擎所維護數據集的SQL語句等信息，持久化到配置庫中的，動態刷新服務器依照配置信息來維持其數據集。
4.3.2.3.3 對業務架構設計的建議
經過以往應用系統的開發經驗，建議：數據集的SQL儘可能簡潔、客戶端的表現層和業務層徹底解耦，如此，就能夠使得相關表觸發器的編寫更加簡單、準確，客戶端的代碼編寫也更加容易和麪向對象化；最好是，數據庫結構的設計也要考慮到是否適合數據動態引擎運行等等；總之，希望能夠更好的滿足性能、準確率、刷新量等等功能外的需求。
4.3.2.4 消息引擎
應用系統軟總線包括技術實現上的、也包括設計規範上的。應用系統設計可面向總線進行，設計者只需識別總線，根據總線的規定去設計，將各組件按照總線接口的標準與總線連接而無需單獨爲各組件設計連線。這就簡化了系統的設計，也簡化了系統的結構，使系統易於擴充和更新。
消息引擎是應用系統軟總線的一個關鍵技術，是各組件聯繫的紐帶，在接口技術中扮演着重要的角色。倚靠目前可以利用的技術，我們可以從以下幾處着手來實現它。
4.3.2.4.1 數據包
在總線上傳輸的數據需要統一的標準進行包裝，用以將參數傳遞給框架中的任意對象，即將彼此無關的參數打包成單一和高效的數據封裝包，以簡化系統的設計，這點可以與物流領域中的集箱和散貨做比方，是一個道理。
當交互的對象被某種形式的邊界隔開，數據傳輸的代價就會很高。邊界可以有多種形式：網絡邊界、進程邊界、域邊界（.NET）和存儲邊界（I/O）等等。當開發人員來回設置和獲取數據時，數據傳輸可能帶來性能上的問題。
爲了避免在對象交互期間的多次往返，一種選擇就是在方法中立即傳遞所有參數。數據包就是這樣一些參數的容器，它是一個通用的容器，將按需容納許多參數來滿足任何業務對象。
數據包另一個好處是，可以應對參數集合頻繁改變的情形，只要往返雙方知道怎麼打包和解析即可。
使用ADO.NET的DataSet對象來作爲數據包的容器是可行的方法之一。數據包利用DataSet可以包含任何數據，並傳遞到框架內的每一層。同時，與數據包交互的業務對象不直接和DataSet打交道，而是調用數據包的標準方法（比如GetData（）），爲業務對象提供統一的交互界面。
4.3.2.4.2 數據字典
此處的數據字典不僅僅是指數據庫概念（就數據庫概念將在持久層中專門討論），而是囊括了信息系統內交互的所有信息的元數據。
架構提供專門的配置工具來構建信息系統的數據字典，並持久化到配置庫中供相關標準組件調用。
數據字典的使用，可以規範開發過程，使得系統設計簡單化。首先是參數的規範，開發人員不必自創參數的命名，少了溝通的障礙，也減少了信息的二義性。其次是值的規範，定義了一套公共的代碼表，爲信息系統提供統一的代碼支持。
數據字典的構建，使得表現層、業務層和持久層間的信息交互可以通過數據字典自動匹配，爲自動化處理（工作流等）等應用提供了基礎平臺。
4.3.2.4.3 MessageQueue
利用 Microsoft Windows“消息隊列”，可以通過發送和接收消息方便地與應用系統進行快速可靠的通信。消息處理和消息爲基於服務器的應用程序組件之間的進程間通信提供了強大靈活的機制。同組件間的直接調用相比，它們具有若干優點，其中包括：
1，穩定性
組件失敗對消息的影響程度遠遠小於組件間的直接調用，因爲消息存儲在隊列中並一直留在那裏，直到被適當地處理。消息處理同事務處理相似，因爲消息處理是有保證的。
2，消息優先級
更緊急或更重要的消息可在相對不重要的消息之前接收，因此可以爲關鍵的應用程序保證足夠的響應時間。
3，脫機能力
發送消息時，它們可被髮送到臨時隊列中並一直留在那裏，直到被成功地傳遞。當因任何原因對所需隊列的訪問不可用時，用戶可以繼續執行操作。同時，其他操作可以繼續進行，如同消息已經得到了處理一樣，這是因爲網絡連接恢復時消息傳遞是有保證的。
4，事務性消息處理
將多個相關消息耦合爲單個事務，確保消息按順序傳遞、只傳遞一次並且可以從它們的目標隊列中被成功地檢索。如果出現任何錯誤，將取消整個事務。
5，安全性
MessageQueue 組件基於的消息隊列技術使用 Windows 安全來保護訪問控制、提供審覈並對組件發送和接收的消息進行加密和驗證。
4.3.2.4.4 應用範圍
如何合理地使用MQ技術，是構建可編寫、可部署的應用系統所必須考慮的問題。通過對MQ技術的瞭解，它不是特別適合於數據交互量大、或者不需維持歷史消息的系統，而適合於用戶間的消息通知（必達消息）、協同工作模式下的應用系統。
4.3.2.5 安全引擎
計算機技術安全管理的範圍很廣，可以包括網絡安全性、數據安全性、操作系統安全性以及應用程序安全性等。很多方面的安全性管理大都已經有成熟的產品了，我們只需根據自己需要有選擇性的使用就可達到自己的目的了。本章中有關關涉及‘安全管理’一詞均只針對應用系統中有關對象與數據而言的範圍。
4.3.2.5.1 名稱解釋
主體：即可以嚮應用系統發出應用請求的任何實體，包括各種用戶、其它與本系統有接口的應用程序、非法入侵者。系統必須具有識別主體的能力，接口實際上也是由用戶登記的，故主要問題是校驗用戶身份的合法性，系統應建立用戶鑑別機構以驗證用戶身份。
用戶：用戶就是一個可以獨立訪問計算機系統中的數據或者用數據表示的其它資源的主體，用戶在一般情況下是指人。
權限：權限是對計算機系統中的數據或者用數據表示的其它資源進行訪問的許可。可分爲對象訪問控制和數據訪問控制兩種。
對象訪問控制：用一個二元組來表示：（控制對象，訪問類型）。其中的控制對象表示系統中一切需要進行訪問控制的資源，訪問類型是指對於相應的受控對象的訪問控制，如：讀取、修改、刪除等等。
數據訪問控制：如果不對數據訪問加以控制，系統的安全性是得不到保證的，容易發生數據泄密事件。所以在權限中必須對對象可訪問的數據進行按不同的等級給予加密保護。我們同樣用一個二元組來表示：（控制對象，謂詞）。權限最終可以組合成如下形式：（控制對象，訪問類型，謂詞）。
角色：角色是指一個組織或任務中的工作或位置，它代表了一種資格、權利和責任。
用戶委派：用戶委派是用戶與角色之間的一個二元關係。
權限配置：權限配置是角色與權限之間的一個二元關係。
4.3.2.5.2 總體構思
架構應該能夠做到對對象控制、菜單控制、數據集的控制，將應用系統的安全管理單獨的分離出來，並制定一些整個系統通用的安全準則。應用系統開發者在業務設計時不要過多的考慮程序安全性的問題，而只需遵循系統的安全準則即可，把主要精力花費在系統的業務功能上。
1，基於角色對用戶組進行訪問控制
對一組用戶比對單個用戶進行訪問控制更加合理，用戶組代表了具有相近工作性質的一組用戶的集合，可以委派完成用戶組工作的角色以控制用戶組的權限範圍（當然我們也可以把角色看成是我們系統中一個特定用戶組）。同時支持角色的繼承和多繼承。通過改變用戶的當前角色集就可以改變用戶的權限，而改變某種角色所含的權限時又可以改變一組用戶的權限，基於這種訪問控制方式有3個方面的作用：（1）簡化了權限管理，避免直接在用戶和數據之間進行授權和取消。研究表明，用戶所具有的權限易於發生改變，而某種角色所對應的權限更加穩定；（2）有利於合理劃分職責，用戶只有其所應具有權限，這樣可以避免越權行爲，有關用戶組的關係描述正是對此的支持；（c）防止權力濫用，敏感的工作分配給若干個不同的用戶完成，需要合作的操作序列（工作流）不能由單個用戶完成。
2，支持動態地改變用戶的權限
安全管理考慮了訪問權限不是靜態，而是動態的情況。當應用系統使用工作流時，可通過工作流引擎與安全管理控制核心的接口，動態分配用戶完成當前工作流環節所需的權限。
3，權限的相互關聯
各種權限不是互相獨立而是相互關聯的，而且權限可以感知到其它用戶操作，這可以描述有關協同權限。例如在給數據編輯控件授權只讀權限時，收回用戶對數據插入和刪除權限，該權限允許感知其它用戶的操作，諸如某用戶改變了數據等等。
4，提供方便的授權/取消機制和檢查機制：
只要進行簡單的賦值操作即可完成授權，同時由角色分配規則和主體訪問規則控制這種授權機制的應用。
5，用戶之間的授權關係：
依據角色指派關係，運行系統中的用戶自身可以對角色進行管理，這提供了又一種動態改變用戶權限的手段。通常，角色指派的權力都在系統中具有管理責任的用戶手中。
用戶通過專用客戶端的登陸窗口進入應用系統，專用客戶端依此管理用戶的權限等信息，並根據用戶權限動態生成菜單項和其他的加載項，如工具欄、列表框等等。用戶通過專用客戶端調用具體的組件，而組件（程序集）在用戶的操作過程中動態加載、緩存和管理，即插件的方式。專用客戶端還負責構件（程序集）的下載升級，做到一次安裝永久使用。
4.4 License版權
爲保護應用系統產品的版權，需要在架構中提供版權限制功能，以限制用戶同時登陸數量。
可提供公鑰予客戶對系統進行版權升級，而公鑰是通過開放用戶數、客戶公司名等等信息計算而來。
5 架構層次
如上圖，軟件開發架構開發層次，上層的開發基本將基於下層提供的功能進行開發。
6 設計規範
遵照《.NET設計規範》進行代碼編寫。
7 風險控制
從前文分析，公司將來的產品主要以圖形化交互界面爲主，那麼圖形對象在.NET上的應用，是否能夠支持大批量數據的動態刷新、界面的響應週期等等指標，都需要經過測試才能下結論，這甚至是整個框架是否能夠基於.NET開發平臺之上構建的前提條件。如果拿輕量級的TATUKGIS在壓力測試下也未能達到上述要求的話，那是否中止以.NET開發平臺爲主的框架設計，而轉向以win32（Delphi/C++）開發平臺爲主的框架設計，就應該重新考量的了。
8 技術準備與技術培訓
9 實施方案
技術架構的研發是個迭代、逐步完善的過程，不可能是一蹴而就的工作，同時必須實時響應它所支撐的產品線開發的需求。所以組建專職的技術架構研發組織，可以保障技術架構的研發持續穩固的進行下去，並能切實發揮其效用。
架構的實施，必須得到全體開發人員的配合和理解。因爲應用系統的業務分析、邏輯分層、數據庫設計等等，都是能夠脫離本架構限制，隨意發揮的。在應用系統的設計開發中，哪些可行、哪些不可行，都需要對本架構、.NET平臺技術、分佈式組件開發等技術和方法論，需要有一系列的領悟和使用經驗，並能夠融入到自己的開發當中，才能使業務架構與技術架構完美結合，設計出好的產品。但這些又不是本架構能夠做到的，需要公司相關制度、組織結構、開發團隊的配合
轉載自http://blog.csdn.net/phenixiii/article/month/2007/11
