摘要 了的Pet Shop
企業版本是怎樣幫助企業解決實際中的業務問題
Net Pet Shop
驗證了怎樣利框架和Visual 來開發最佳的企業級系統
就如Sun公司的Java
; Pet Store J
EE
; Blueprint application
它也是一個最佳的系統實現
介紹 NET 寵物店程序開發於
年
月
它描述了
Net開發者怎樣利框架和Visual 開發最佳的系統
下面關於寵物店和原來的J
EE寵物店的討論涉及了企業級系統的一些特性
如可靠性和伸縮性
對於一個系統要部署成企業級
一定要考慮它的安全性
可靠性
可伸縮性
可管理性以及與已有的系統和數據進行協同的工作
以前版本的寵物店系統所表現出來的成本優勢
性能和開發效率在
Net平台上仍然存在
本文通過描述了
Net支持的其他的企業級需求
從而把寵物店的討論引向深入
許多企業都有他們存在於不同系統中的分布的數據
比如存貨數據在一個存貨控制系統中
而客戶資料數據卻在他們的CRM系統中
我們的系統需要處理這些不同數據庫中的數據
並且保證數據的更改在這些系統中正確進行
要達到這些要求
我們需要跨數據庫的事務處理
寵物店企業級版本是為了展平台上的技術可以很好的支持那些企業級系統的特性
它在處理現實世界中存在的數據存儲方面提供了一個可靠的
可伸縮的系統
寵物店企業級版本處理這樣的一些情形
如客戶數據存在於一個服務器上的客戶數據庫系統中
而客戶定單數據存在於物理上不同的服務器上的一個不同的數據庫系統中
這樣的情形在許多機構中是一個普遍的現象
為了保證客戶數據和客戶定單數據永遠是正確的
需要一個包含這兩個數據源的分布式系統
本文討論了企業級系統中處理事務的不同機制
給出了每種機制的示例代碼
討論了一些最佳做法
本文中的代碼是用c#寫成的
但所有的方法和技術一樣適用於
本文所討論的跨多個數據庫的分布式事務對於一個系統來說早已被證實具有優良的性能和伸縮性
這裡還測試平台上的幾種事務機制的性能
詳細的列舉和描述了它們的結果
從這些結果中
我們可以清楚的看從功能上和性能上都提供了優秀的企業級事務支持
本文還包含了寵物店的一些介紹
它的初始架構和實現
以及為了支持企業級特性對它的一些改動
還詳細討論了不同的事務方式和他們的測試性能結果圖
請參閱how Sun Microsystems
Java Pet Store J
EE BluePrint Application was implemented using Microsoft
NET
假設的情景 假設一個可以在線訂購寵物的電子商務企業
當你進入系統後
你可以浏覽
查詢從犬類到爬行動物的各種類型的寵物
一個典型的寵物店系統包括
◆ 主頁
當你打開系統後載入的頁面
◆ 類別浏覽 –頂層有五種類別
每種類別下面都有若干產品
◆ 產品 –當系統裡面的一個產品被選種時
產品的屬性就被顯示出來
典型的如公或者母
◆ 產品明細 –每種產品屬性的詳細說明
如照片
價格和庫存數量
◆ 購物車 –允許客戶去維護一個購物車(增加
刪除
更新數量)
◆ 校驗 –只讀地顯示一個購物車信息
◆ 登錄定向 –當用戶在校驗頁面上選擇繼續的時候
如果他還沒有登錄
則會定向到登錄頁面
◆ 驗證登錄 –當登錄被驗證後
就會轉到信用卡信息和訂購地址信息頁面
◆ 確認定單 –定單和客戶地址信息被顯示出來等待確認
◆ 提交定單 –最後的一個步驟
在這裡定單被提交到數據庫
寵物店的一個例子如圖
圖Net寵物店 Net寵物店的總體邏輯架構如圖
圖Net寵物店邏輯架構 有三個邏輯層
表示層
中間層
數據層
這三層可以使不同特征的分布式系統進行清晰的部署
邏輯層被裝成一裝配(用C#類庫實現)
對數據庫的訪問是用一個類來處理所有的與SQL Server Managed provider的交互
用存儲過程來存取數據
這個系統利用實現了完全的邏輯上的三層架構
表現平台上的最佳實踐
圖Net寵物店系統的物理部署圖 程序架構 圖
是用來表現我們的設計的詳細圖
我們可以看到寵物店每層的實現和交互細節
圖架構設想 數據庫 數據庫有如下的表
表格數據庫表名 Net寵物店的事務實現 原有寵物店中Order類的addOrder方法所調用的存儲過程中用到了數據庫事務
這個調用涉及到了四個表的數據
需要定義ACID屬性
因為如果一個定單被創建
庫存數據需要被調整
存儲過程利用了一個xml文檔做參數
插入定單數據
定單明細
插入定單狀態數據
更新定單裡涉及到的產品的庫存數據
我們的目標是從單一數據庫架構變為分布式數據庫架構
也就是客戶
產品和庫存數據存在一個數據庫裡面
定單存在於另外的一個數據庫中
為了達到這個目標
我們需要轉移到一個企業服務型架構
這是唯一的一種可以控制分布式事務和提供兩階段的提交的機制
為了轉移到企業服務級
我們需要考察幾種情形的影響
◆ 引入企業服務類庫
但是用數據庫事務/ADO
NET事務
◆ 引入企業服務類庫
利用它來控制事務
◆ 引入企業服務類庫
利用它來控制分布式事務
為了實現分布式事務
我們需要修改addOrder方法和數據庫交互的方式
在單一的數據庫情形下
我們利用了一個存儲過程
對於分布式
我們需要變為兩個存儲過程
每個數據庫一個
我們意識到原先的存儲過程在最後表之間用了連接
現在這些表存在於不同的數據庫中
所以我們最好還是把這些實現放到中間層中
用動態生成SQL語句
為了顯示引入企業服務類庫對於每個組件的影響
我們設計寵物店的幾個版本
◆ 用最初寵物店v
作為基礎
◆ 利用ADO
NET事務寵物店
◆ 使用企業服務類庫和ADO
NET事務(企業服務的事務屬性設置為
不支持
)
◆ 利用企業服務的事務(事務屬性在Order組件被設置為
需要
ADO
NET的事務去掉)
◆ 利用企業服務來處理分布式事務
分布式情形下的數據庫設計 圖寵物店數據庫模型 圖定單數據庫模型 Net的事務機制 Net開發者可以使用四種機制
◆ 數據庫事務
◆ ADO
NET事務
◆ ASP
NET事務
◆ 企業服務級事務
每種機制在以下的幾方面有各自的優勢和劣勢
性能
代碼數量
部署設置
許多開發者都很熟悉數據庫的事務
在這種情形下
中間層調用數據庫的存儲過程
存儲過程中開始一個事務
如果每個語句都執行成功則提交
如果有錯誤發生時就會回滾
如果你的事務需要幾個調用
例如
你需要插入多個定單明細到一個表中
但不想用一個xml文檔或者傳遞一個很長的字符串
這些都需要在存儲過程中被解析
你可以用ADO
NET事務機制
ADO
NET事務允許你在當前的連接上創建一個事務上下文
運行對數據庫的多次調用
在最後或者提交或者回滾
ASP
NET事務是在Web應用程序的頁面層工作
你只要簡單的在頁面屬性中加一個
Transaction=
Required
這樣在頁面中的事件處理都作為頁面整個事務的一部分
任何處理出現錯誤
則所有的處理都將回滾
企業服務型組件通過資源管理器和分布事務控制器(DTC)來實現事務
當ASP
NET
一個數據庫的調用或者事務中涉及到的其他資源發生錯誤或者異常時
整個事務將被回滾
企業服務建立在COM+技術的基礎上來處理事務
熟悉COM+的開發者應該理解企業服務
應該被提到實現一個事務的這些不同方式之間可能是互斥的
如果你混合使用數據庫事務和企業服務事務
你就會得到一個錯誤
這是因為你會得到重復的提交
你在企業服務中可能提交一個在數據庫事務中已經提交了的事務
這樣已經沒有事務上下文來進行提交動作了
同樣的問題如在數據庫事務中提交了一個事務
但在企業服務中卻因為在系統中發生異常而回滾
(未完待續)
From:http://tw.wingwit.com/Article/program/ASP/201311/21714.html