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 请欢迎转载，但需保留版权。