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 SericveWCFASP.NET MVC的支持略有欠缺。对于ORMIoCAOP等编程思想的概括几乎为空白。

 

  考虑到以上的问题,我个人准备对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

  欢迎转载,但需保留版权。

 

作者:刘冬.NET 博客地址:http://www.cnblogs.com/GoodHelper/ 欢迎转载,但须保留版权
posted @ 2010-06-17 12:42  冬子哥  阅读(18754)  评论(49编辑  收藏  举报