Spring.NET企業架構實踐之 Nhibernate + WCF + ASP.NET MVC + NVelocity 對PetShop4.0重構(一)——架構設計

　　　　　　　　　　

　　PetShop4.0是微軟針對.NET企業系統推出的一個範例。業界有許多.NET與J2EE之爭，許多資料是從微軟的PetShop和Sun的PetStore而來。這種爭論不可避免帶有濃厚的商業色彩，對於我們開發人員而言，沒有必要過多關注。然而PetShop隨著版本的不斷更新，至現在基於.Net 2.0的PetShop4.0為止，整個設計逐漸層得成熟而優雅，而且有很多可以借鑒之處。PetShop是一個小型的項目，系統架構與代碼都比較簡單，卻也凸現了許多頗有價值的設計與開發理念。

　　然而PetShop4.0存在很多爭議，我想園子裡一定有很多PetShop4.0的“粉絲”，重構PetShop4.0會引發很多爭議，我希望園子裡的朋友以“交流技術”的心態來看待此問題。對於“重構”，我只是以我個人的觀點闡述了PetShop4.0一些不合理的地方，並加以“修改”，同時引入了一些我“片面”的架構設計思想。

　　我個人認為PetShop4.0存在以下的弊端：

　　1、入門層級的架構，不完全適於中、進階開發人員學習。

　　PetShop4.0作為.NET三層的一種入門型架構。目前據我瞭解，大多數公司的架構模式都採用或者效仿PetShop4.0。對此我個人認為：作為.NET開發人員來說，這樣並沒有完全理解分層的真正意義，照搬PetShop4.0，而沒有真正靈活應用PetShop4.0。我想，針對真正的大型項目，在擴充性，重用性，負載平衡上，PetShop4.0是很吃力的。對於伺服器叢集的分布式的應用來說是個空白。

　　2、錯誤的引導程式員對架構的深入瞭解。　　

　　很多.NET開發人員習慣認為：學會PetShop4.0以後就學會了大多數公司的架構。對此我個人認為這是.NE開發人員的悲哀。目前可以這麼說，PetShop4.0影響了一代.NET程式員的架構思路，並把這代程式員的設計思路給限定“死”了。習慣性認為架構就是“DAL,BLL,UI”。我想，這樣就會阻礙出架構設計。我認為PetShop4.0僅僅是一個“特列”，而不是一種通用型架構。

　　3、移植性和重用性偏弱。

　　對於SQLServerDAL和OracleDAL來說，在實際中增加第三種資料庫就需要再寫一個DAL，這樣會增加我們的開發成本，我個人建議使用ORM架構來實現比較恰當。因為這樣便於資料庫的移植。在持久層中，基本上每個表都需要對應的CRUD，建議使用Repository將代碼內聚起來。PetShop4.0的SQL語句是寫在類裡的，這一點我比較反對，我傾向於把SQL語句寫在設定檔或者模板檔案裡(如：ibatis.net)，這樣看上去會更靈活。

　　4、僅適用於展示.NET2.0的特性，在NET3.5以上環境卻失去了優勢。

　　PetShop4.0發布已經有好幾年了，在新技術層出不窮的時代。PetShop4.0對於AJAX，Web Sericve、WCF、ASP.NET MVC的支援略有欠缺。對於ORM、IoC、AOP等編程思想的概括幾乎為空白。

 

　　考慮到以上的問題，我個人準備對PetShop4.0進行重構，以便新技術發展的需要。

 

---------------------------------------------------------------------------------------------------------------------------------

　　圖1是重構後的架構圖：

(圖1)

 

 

 

　　從圖1中能夠看出，該架構的持久層選擇了一種ORM架構。這樣能夠便於資料庫的移植，除了能相容SQL Server和Oralce以外，還支援更多的資料庫。而並非針對每種資料庫來寫一個DAL。

　　對於資料庫的事務來說，該架構採用配製的方式來實現資料庫的“自動事務策略”。這樣能減少我們的代碼量和降低開發成本。

　　作為一個子系統的“門面”部分，相當外部系統來說，封裝了資料庫持久層(DAO)和伺服器層(Service)。外部系統不關心其子系統內部的具體實現，而是通過“契約(Contract)”來互動。

 

----------------------------------------------------------------------------------------------------------------------

　　讓我們看一下原PetShop4.0的資料庫：這裡有3個資料庫。當伺服器負載過重時，通常不會把這3個庫部署到同一台伺服器上，而是分別部署到不同伺服器上。接下來，對於同一個持久層訪問3個資料庫來說也是不合理的。這樣，我能把每個資料庫看做一個子系統，通過分布式技術將這3個子系統串連起來，從而分攤壓力和降低子系統與子系統之間的耦合程度。我個人認為，在設計體統架構體系中，我們應該控制子系統之間的耦合程式。在某個子系統中引用了其他“平級”的子系統，這樣的做法並非是很明智的。

 

圖2是重構後服務於服務之間的：

 

(圖2)

 

上述三個子系統相對是“平級”的，它們之間不應該發生耦合。用戶端能夠同時訪問這三個子系統；或者增加一個二級服務，讓二級服務訪問這三個子系統，用戶端只依賴二級服務，而不是直接依賴三個子系統，就相當於這個“二級”服務是這三個子系統的門面。根據不同的需要，用戶端可以是一個，也可以是多個，管理員使用一個用戶端，客戶使用另一個用戶端。

 

 

　　出處http://www.cnblogs.com/GoodHelper/archive/2010/06/17/SpringNet_PetShop4_1.html 請

　　歡迎轉載，但需保留著作權。