程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> .NET網頁編程 >> 關於.NET >> Spring.NET企業架構實踐(一)

Spring.NET企業架構實踐(一)

編輯:關於.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

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved