petshop40功能的使用说明.docx
《petshop40功能的使用说明.docx》由会员分享，可在线阅读，更多相关《petshop40功能的使用说明.docx（108页珍藏版）》请在冰豆网上搜索。
petshop40功能的使用说明
petshop40功能的使用说明.txtゅ你不用一上线看见莪在线，就急着隐身，放心。
莪不会去缠你。
说好的不离不弃现在反而自己却做不到╮-----------------------Page1-----------------------
pettshop4.0详详解之一（系系统架构设计）
前言言：
PetShop是一个范例，微软用它来来展示.Net企企业系统开发发的能力。
业界界有许多.Neet和
J2EE之争，许多多数据是从微微软的PetShoop和Sun的的PetStore而而来。
这种争争论不可避免免带有
浓厚厚的商业色彩，，对于我们开开发人员而言言，没有必要过过多关注。
然然而PetShopp随着版本的的不断
更新新，至现在基于于.Net2.0的的PetShop44.0为止，整整个设计逐渐变变得成熟而优优雅，却又很很多可
以借借鉴之处。
PeetShop是一个个小型的项目目，系统架构构和代码都比较较简单，却也也凸现了许多颇有
价值值的设计和开发发理念。
本系系列试图对PetShop作一一个全方位的解剖，依据的的代码是
PetSShop4.0，可可以从链接
httpp:
//msdn.mmicrosoft.coom/library/ddefault.aspp?
url=/library/en-us/ddnbda/html//bd
asamppet4.asp中获得。
一、PetShop的的系统架构设设计
在软软件体系架构设设计中，分层层式结构是最常见，也是最最重要的一种结构。
微软推推荐的分层式式结构
一般般分为三层，从从下至上分别别为：
数据访问层、业务逻逻辑层（又或或成为领域层））、表示层，如图
所示示：
图一：
三层的分层式结构
数据据访问层：
有时时候也称为是是持久层，其功功能主要是负负责数据库的访问。
简单的的说法就是实实现对
数据据表的Selectt，Insert，UUpdate，Deelete的操作作。
如果要加入入ORM的元元素，那么就会会包
括对对象和数据表之之间的mapping，以及对对象实体的持持久化。
在PeetShop的数数据访问层中，，并
没有有使用ORM，从而导致了代码量的增加加，可以看作作是整个设计实现中的一大大败笔。
-----------------------Page2-----------------------
业务逻辑层：
是整个系统的核心，它和这个系统的业务（领域）有关。
以PetShop为例，业务
逻辑层的相关设计，均和网上宠物店特有的逻辑相关，例如查询宠物，下订单，添加宠物到购物
车等等。
如果涉及到数据库的访问，则调用数据访问层。
表示层：
是系统的UI部分，负责使用者和整个系统的交互。
在这一层中，理想的状态是不应包
括系统的业务逻辑。
表示层中的逻辑代码，仅和界面元素有关。
在PetShop中，是利用ASP.Net
来设计的，因此包含了许多Web控件和相关逻辑。
分层式结构究竟其优势何在？
MartinFowler在《PatternsofEnterpriseApplication
Architecture》一书中给出了答案：
1、开发人员可以只关注整个结构中的其中某一层；
2、可以很容易的用新的实现来替换原有层次的实现；
3、可以降低层和层之间的依赖；
4、有利于标准化；
5、利于各层逻辑的复用。
概括来说，分层式设计可以达至如下目的：
分散关注、松散耦合、逻辑复用、标准定义。
一个好的分层式结构，可以使得开发人员的分工更加明确。
一旦定义好各层次之间的接口，负责
不同逻辑设计的开发人员就可以分散关注，齐头并进。
例如UI人员只需考虑用户界面的体验和
操作，领域的设计人员可以仅关注业务逻辑的设计，而数据库设计人员也不必为繁琐的用户交互
而头疼了。
每个开发人员的任务得到了确认，开发进度就可以迅速的提高。
松散耦合的好处是显而易见的。
如果一个系统没有分层，那么各自的逻辑都紧紧纠缠在一起，彼
此间相互依赖，谁都是不可替换的。
一旦发生改变，则牵一发而动全身，对项目的影响极为严重。
降低层和层间的依赖性，既可以良好地保证未来的可扩展，在复用性上也是优势明显。
每个功能
模块一旦定义好统一的接口，就可以被各个模块所调用，而不用为相同的功能进行重复地开发。
进行好的分层式结构设计，标准也是必不可少的。
只有在一定程度的标准化基础上，这个系统才
是可扩展的，可替换的。
而层和层之间的通信也必然保证了接口的标准化。
“金无足赤，人无完人”，分层式结构也不可避免具有一些缺陷：
1、降低了系统的性能。
这是不言而喻的。
如果不采用分层式结构，很多业务可以直接造访数据
库，以此获取相应的数据，如今却必须通过中间层来完成。
2、有时会导致级联的修改。
这种修改尤其体现在自上而下的方向。
如果在表示层中需要增加一
个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相
应的代码。
前面提到，PetShop的表示层是用ASP.Net设计的，也就是说，它应是一个BS系统。
在.Net
中，标准的BS分层式结构如下图所示：
-----------------------Page3-----------------------
图二：
.Net中标准的BSS分层式结构构
随着着PetShop版版本的更新，其分层式结构构也在不断的的完善，例如PetShop2.0，就没有采采用标
准的的三层式结构，，如图三：
图三：
PettShop2.0的的体系架构
从图图中我们可以看看到，并没有有明显的数据据访问层设计。
。
这样的设计计虽然提高了数据访问的性性能，
但也也同时导致了业业务逻辑层和和数据访问的的职责混乱。
一一旦要求支持持的数据库发生生变化，或者者需要
修改改数据访问的逻逻辑，由于没没有清晰的分层，会导致项项目作大的修修改。
而随着硬硬件系统性能能的提
高，以及充分利用用缓存、异步步处理等机制制，分层式结构构所带来的性性能影响几乎可以忽略不计计。
PetSShop3.0纠正正了此前层次次不明的问题题，将数据访问问逻辑作为单单独的一层独立出来：
-----------------------Page4-----------------------
图四：
PettShop3.0的的体系架构
PetSShop4.0基本本上延续了33.0的结构，但在性能上作作了一定的改改进，引入了了缓存和异步处处理
机制制，同时又充分分利用了ASSP.Net2.0的的新功能MemberShip，因此PetShhop4.0的系统架
构图图如下所示：
图五：
PettShop4.0的的体系架构
-----------------------Page5-----------------------
比较较3.0和4.0的系统架构图图，其核心的的内容并没有发生变化。
在在数据访问层层（DAL）中，仍
然采采用DALInteerface抽象出出数据访问逻逻辑，并以DAALFactory作作为数据访问问层对象的工工厂模
块。
对于DALInterface而言言，分别有支支持MS-SQLL的SQLSeerverDAL和和支持Oracle的
OracleDAL具体体实现。
而Model模块则包含了数据实实体对象。
其详详细的模块结结构图如下所所示：
图六：
数据据访问层的模模块结构图
可以以看到，在数据据访问层中，完全采用了““面向接口编程”思想。
抽象出来的IDDAL模块，脱脱离了
和具具体数据库的依依赖，从而使使得整个数据据访问层利于数数据库迁移。
DALFactorry模块专门管管理
DALL对象的创建建，便于业务逻逻辑层访问。
SQLServerDAL和OraacleDAL模块块均实现IDAAL模
块的的接口，其中包包含的逻辑就就是对数据库库的Select，IInsert，Upddate和Deleete操作。
因因为数
据库库类型的不同，，对数据库的的操作也有所所不同，代码也也会因此有所所区别。
此外外，抽象出来的的IDAL模块块，除了解除了了向下的依赖赖之外，对于其上的业务逻逻辑层，同样样仅存
在弱弱依赖关系，如如下图所示：
-----------------------Page6-----------------------
图七：
业务务逻辑层的模模块结构图
图七七中BLL是业业务逻辑层的核核心模块，它它包含了整个个系统的核心业业务。
在业务务逻辑层中，不不能
直接接访问数据库，，而必须通过过数据访问层层。
注意图中对对数据访问业业务的调用，是通过接口模模块
IDAAL来完成的。
既然和具体体的数据访问逻逻辑无关，则则层和层之间的关系就是松松散耦合的。
如果
此时时需要修改数据据访问层的具具体实现，只要要不涉及到IIDAL的接口定义，那么业业务逻辑层就就不会
受到到任何影响。
毕毕竟，具体实实现的SQLServerDAL和和OracalDAAL根本就和业业务逻辑层没没有半
点关关系。
因为为在PetShopp4.0中引入了异步处理机机制。
插入订订单的策略可以分为同步和和异步，两者者的插
入策策略明显不同，，但对于调用用者而言，插插入订单的接口口是完全一样样的，所以PeetShop4.0中设
计了了IBLLStrateegy模块。
虽虽然在IBLLSStrategy模块块中，仅仅是是简单的IOrdyy，但
derStateg
同时时也给出了一个个范例和信息息，那就是在业务逻辑的处处理中，如果果存在业务操作作的多样化，或者
是今今后可能的变化化，均应利用用抽象的原理。
或者使用接接口，或者使用抽象类，从从而脱离对具具体业
务的的依赖。
不过在在PetShop中，由于业务务逻辑相对简简单，这种思想想体现得不够够明显。
也正正因为
此，PetShop将将核心的业务逻逻辑都放到了了一个模块BLL中，并没有有将具体的实实现和抽象严严格的
按照照模块分开。
所所以表示层和和业务逻辑层层之间的调用关关系，其耦合合度相对较高：
-----------------------Page7-----------------------
图八：
表表示层的模块块结构图
在图图五中，各个层层次中还引入入了辅助的模模块，如数据访访问层的Messsaging模块块，是为异步步插入
订单单的功能提供，，采用了MSSMQ（MicroosoftMessaagingQueuee）技术。
而而表示层的
CaccheDependeency则提供缓存功能。
这这些特殊的模模块，我会在此此后的文章中中详细介绍。
pettshop4.0详详解之二（数数据访问层之数据库访问设设计）
在系系列一中，我从从整体上分析析了PetShop的架构设计计，并提及了了分层的概念。
从本部分开开始，
我将将依次对各层进进行代码级的的分析，以求求获得更加细致致而深入的理理解。
在PetSShop4.0中中，由
于引引入了ASP.NNet2.0的一些新特色，所所以数据层的的内容也更加的广泛和复杂杂，包括：
数数据库
访问问、Messaginng、MembeerShip、Proofile四部分。
在系列二中，我将介绍有有关数据库访访问的
设计计。
在PPetShop中，系统需要处处理的数据库对对象分为两类类：
一是数据实体，对应数数据库中相应应的数
据表表。
它们没有行行为，仅用于于表现对象的的数据。
这些实实体类都被放放到Model程程序集中，例如数
据表表Order对应应的实体类OrrderInfo，其其类图如下：
-----------------------Page8-----------------------
这些些对象并不具有有持久化的功功能，简单地说，它们是作作为数据的载载体，便于业务务逻辑针对相相应数
据表表进行读/写操操作。
虽然这些类的属性分分别映射了数数据表的列，而而每一个对象象实例也恰恰恰对应
于数数据表的每一行行，但这些实实体类却并不不具备对应的数数据库访问能能力。
由于于数据访问层和和业务逻辑层层都将对这些些数据实体进行行操作，因此此程序集Moddel会被这两两层的
模块块所引用。
第二二类数据库对象象则是数据的的业务逻辑对对象。
这里所指指的业务逻辑辑，并非业务逻逻辑层意义上上的领
域（（domain）业业务逻辑（从从这个意义上，，我更倾向于于将业务逻辑层称为“领域域逻辑层”），一般
意义义上说，这些业业务逻辑即为为基本的数据据库操作，包括括Select，IInsert，Upd
date和Delete。
由于于这些业务逻辑辑对象，仅具具有行为而和和数据无关，因因此它们均被被抽象为一个单独的接口模模块
IDAAL，例如数据据表Order对对应的接口IOOrder：
将数数据实体和相关关的数据库操操作分离出来来，符合面向对对象的精神。
首先，它体现了“职责分分离”
的原原则。
将数据实实体和其行为为分开，使得两两者之间依赖赖减弱，当数据行为发生改改变时，并不不影响
Moddel模块中的数据实体对象象，避免了因一一个类职责过过多、过大，从从而导致该类类的引用者发生生“灾
难性性”的影响。
其其次，它体现了“抽象”的精精神，或者说说是“面向接口口编程”的最佳佳体现。
抽象的接
口模模块IDAL，和和具体的数据据库访问实现完完全隔离。
这这种和实现无关的设计，保保证了系统的的可扩
展性性，同时也保证证了数据库的的可移植性。
在PetShopp中，可以支持SQLServver和Oraccle，
那么么它们具体的实实现就分别放放在两个不同同的模块SQLLServerDAL、OracleDAAL中。
以OOrder为例，在SQLServverDAL、OrracleDAL两两个模块中，有有不同的实现现，但它们同时又
都实实现了IOrder接口，如图图：
从数数据库的实现来来看，PetShhop体现出了了没有ORM框框架的臃肿和和丑陋。
由于于要对数据表进进行
Inseert和Selecct操作，以SSQLServer为例，就使用用了SqlCommmand，SqqlParameter，
SqlDDataReader等对象，以以完成这些操作作。
尤其复杂杂的是Parammeter的传递递，在PetShhop
-----------------------Page9-----------------------
中，使用了大量的字符串常量量来保存参数数的名称。
此外外，PetShopp还专门为SSQLServer和
Oracle提供了抽抽象的Helpeer类，包装了了一些常用的操作，如ExxecuteNonQQuery、
ExeecuteReader等方法。
在没没有ORM的情情况下，使用用Helper类是是一个比较好好的策略，利用用它来完成数数据库基本操操作的
封装装，可以减少很很多和数据库库操作有关的的代码，这体现现了对象复用用的原则。
PeetShop将这些
Helpper类统一放放到DBUtilitty模块中，不不同数据库的的Helper类暴暴露的方法基基本相同，只除除了
一些些特殊的要求，，例如Oraccle中处理boool类型的方方式就和SQLServer不同同，从而专门门提供
了OOraBit和OrraBool方法。
。
此外，Helpper类中的方方法均为stattic方法，以利利于调用。
OracleHelper的的类图如下：
对于于数据访问层来来说，最头疼疼的是SQL语语句的处理。
在早期的CSS结构中，由由于未采用三层式
架构构设计，数据访访问层和业务务逻辑层是紧紧密糅合在一起起的，因此，SQL语句遍遍布和系统的每每一
个角角落。
这给程序序的维护带来极大的困难。
。
此外，由于OOracle使用的的是PL-SQLL，而SQLSeerver
和SSybase等使用用的是T-SQQL，两者虽然都都遵循了标准准SQL的语法法，但在很多细细节上仍有区区别，
如果果将SQL语句句大量的使用到程序中，无无疑为可能的的数据库移植也也带来了困难难。
最好好的方法是采用用存储过程。
这种方法使得程序更加整整洁，此外，由于存储过程程可以以数据据库脚
本的的形式存在，也也便于移植和和修改。
但这种种方式仍然有有缺陷。
一是存储过程的测测试相对困难难。
虽
然有有相应的调试工工具，但比起起对代码的调试试而言，仍然然比较复杂且且不方便。
二是是对系统的更更新带
来障障碍。
如果数据据库访问是由由程序完成，在.Net平台台下，我们仅需需要在修改程程序后，将重新编
译的的程序集xcoppy到部署的服服务器上即可可。
如果使用用了存储过程，，出于安全的的考虑，必须须有专
门的的DBA重新运运行存储过程程的脚本，部署署的方式受到到了限制。
我曾曾经在一个项目中，利用一一个专门的表表来存放SQLL语句。
如要使使用相关的SSQL语句，就就利
用关关键字搜索获得得对应语句。
这种做法近似于存储过程程的调用，但但却避免了部署署上的问题。
然而
这种种方式却在性能能上无法得到到保证。
它仅适适合于SQL语语句较少的场场景。
不过，利利用良好的设设计，
-----------------------Page10-----------------------
我们可以为各种业务提供不同的表来存放SQL语句。
同样的道理，这些SQL语句也可以存放
到XML文件中，更有利于系统的扩展或修改。
不过前提是，我们需要为它提供专门的SQL语
句管理工具。
SQL语句的使用无法避免，如何更好的使用SQL语句也无定论，但有一个原则值得我们遵守，
就是“应该尽量让SQL语句尽存在于数据访问层的具体实现中”。
当然，如果使用ORM，那么一切就变得不同了。
因为ORM框架已经为数据访问提供了基本的
Select，Insert，Update和Delete操作了。
例如在NHibernate中，我们可以直接调用ISession
对象的Save方法，来Insert（或者说是Create）一个数据实体对象：
publicvoidInsert（OrderInfoorder）
{
ISessions=Sessions.GetSession（）;
ITransactiontrans=null;
try
{
trans=s.BeginTransaction（）;
s.Save（order）;
trans.Commit（）;
}
finally
{
s.Close（）;
}
}
没有SQL语句，也没有那些烦人的Parameters，甚至不需要专门去考虑事务。
此外，这样的
设计，也是和数据库无关的，NHibernate可以通过Dialect（方言）的机制支持不同的数据库。
唯一要做的是，我们需要为OrderInfo定义hbm文件。
当然，ORM框架并非是万能的，面对纷繁复杂的业务逻辑，它并不能完全消灭SQL语句，以
及替代复杂的数据库访问逻辑，但它却很好的体现了“80/20（或90/10）法则”（也被称为“帕
累托法则”），也就是说：
花比较少（10%-20%）的力气就可以解决大部分（80%-90%）的
问题，而要解决剩下的少部分问题则需要多得多的努力。
至少，那些在数据访问层中占据了绝大
部分的CRUD操作，通过利用ORM框架，我们就仅需要付出极少数时间和精力来解决它们了。
这无疑缩短了整个项目开发的周期。
还是回到对PetShop的讨论上来。
现在我们已经有了数据实体，数据对象的抽象接口和实现，
可以说有关数据库访问的主体就已经完成了。
留待我们的还有两个问题需要解决：
1、数据对象创建的管理
2、利于数据库的移植
在PetShop中，要创建的数据对象包括Order，Product，Category，Inventory，Item。
在前面的设计中，这些对象已经被抽象为对应的接口，而其实现则根据数据库的不同而有所不同。
也就是说，创建的对象有多种类别，而每种类别又有不同的实现，这是典型的抽象工厂模式的应
-----------------------Page11-----------------------
用场场景。
而上面所所述的两个问问题，也都可以以通过抽象工工厂模式来解解决。
标准的抽抽象工厂模式式类图
如下下：
例如如，创建SQLLServer的Order对象如如下：
PetSShopFactorryfactory==newSQLSServerFactoory（）;
IOrdder=factoory.CreateOOrder（）;
要考考虑到数据库的可移植性，则factory必须作为一个个全局变量，并在主程序运行时被实例例化。
但这这样的设计虽然然已经达到了了“封装变化””的目的，但在在创建PetShhopFactory对象时，仍不不可
避免免的出现了具体体的类SQLSServerFactoory，也即是是说，程序在这这个层面上产产生了和
SQLLServerFacttory的强依赖赖。
一旦整个个系统要求支支持Oracle，那么还需要修改这行代码码为：
PetSShopFactorryfactory==neworaclleFactory（）;
修改改代码的这种行行为显然是不不可接受的。
解决的办法是是“依赖注入””。
“依赖注入入”的功能通常常是用
专门门的IoC容器器提供的，在Jaava平台下，这样的容器包包括Spring，PicoContainer等。
而在在.Net
平台台下，最常见的的则是Sprinng.Net。
不过过，在PetShoop系统中，并并不需要专门的容器来实现现“依
赖注注入”，简单的的做法还是利用用配置文件和和反射功能来实现。
也就是是说，我们可以在web.coonfig
文件件中，配置好具具体的Factoory对象的完完整的类名。
然然而，当我们利利用配置文件件和反射功能能时，
具体体工厂的创建就就显得有些“画蛇添足”了，我们完全可可以在配置文文件中，直接指指向具体的数数据库
对象象实现类，例如如PetShop..SQLServerrDAL.IOrder。
那么，抽象象工厂模式中中的相关工厂厂就可
以简简化为一个工厂厂类了，所以以我将这种模式式称之为“具有简单工厂特特质的抽象工工厂模式”，其其类图
如下下：
-----------------------Page12-----------------------
DattaAccess类完完全取代了前前面创建的工工厂类体系，它它是一个seaaled类，其中中创建各种数数据对
象的的方法，均为静静态方法。
之之所以能用这个个类达到抽象象工厂的目的，是因为配置置文件和反射射的运
用，如下的代码片片断所示：
pubblicsealedccla
升级会员 