微软PetShop4.0代码深度解析：架构、设计模式与数据库

5星 · 超过95%的资源需积分: 0 111 浏览量更新于2024-07-24 收藏 1.63MB PDF 举报

本文档深入剖析了微软的PetShop4.0代码，主要关注于其架构和技术细节。首先，作者对整个项目的版权进行了声明，并介绍了项目概述和架构分析，包括项目的主要组成部分和设计原则。PetShop4采用的是.NET框架，可能涉及到了如ASP.NET、AOP（面向切面编程）等技术，展示了设计模式在实际应用中的运用。在代码解析部分，作者逐层拆解了PetShop的系统结构，包括数据访问层的设计。这部分详细讲解了数据库访问策略，如何通过ADO.NET或者Entity Framework与SQL Server交互，以及消息处理机制。此外，还讨论了ASP.NET缓存的使用，如何优化性能，以及业务逻辑层和表示层的设计，这些都是确保系统高效运作的关键。困惑和心得部分分享了开发者在使用过程中遇到的问题，如商品库存管理的Invertory类实现、SQLServerDAL和order类的具体操作，以及对SQLHelper.GetCachedParameters方法中缓存机制的理解。同时，还探讨了DALFactory抽象工厂的设计，异时消息处理队列抽象工厂的创建，以及异步订单插入的挑战。面向接口编程的思想和IList与List之间的选择也被提及，反映了对编程原则的思考。数据库解读是文档的重要组成部分，分别介绍了PetShop数据库的设计和组织方式，以及两个具体章节的内容。这有助于读者理解数据模型和关系设计。最后，文档对比了PetShop架构与ORM（对象关系映射）架构的异同，通过概述、PetShop的体系结构、ORM的基本概念，以及两者在实现和性能上的对比，帮助读者理解选择特定架构的原因和考量。这篇代码分析提供了丰富的技术细节，不仅有利于开发者学习和参考，也揭示了PetShop4.0在实际开发中的最佳实践和潜在问题，对于深入理解微软的.NET平台和ASP.NET应用有着很高的价值。

csAxp

河北工业大学——软件工程与理论整理：虾皮

了困难。

最好的方法是采用存储过程。这种方法使得程序更加整洁，此外，由于存储过程可以以

数据库脚本的形式存在，也便于移植和修改。但这种方式仍然有缺陷。一是存储过程的测试

相对困难。虽然有相应的调试工具，但比起对代码的调试而言，仍然比较复杂且不方便。二

是对系统的更新带来障碍。如果数据库访问是由程序完成，在.Net 平台下，我们仅需要在修

改程序后，将重新编译的程序集 xcopy 到部署的服务器上即可。如果使用了存储过程，出于

安全的考虑，必须有专门的 DBA 重新运行存储过程的脚本，部署的方式受到了限制。

我曾经在一个项目中，利用一个专门的表来存放 SQL 语句。如要使用相关的 SQL 语句，

就利用关键字搜索获得对应语句。这种做法近似于存储过程的调用，但却避免了部署上的问

题。然而这种方式却在性能上无法得到保证。它仅适合于 SQL 语句较少的场景。不过，利

用良好的设计，我们可以为各种业务提供不同的表来存放 SQL 语句。同样的道理，这些 SQL

语句也可以存放到 XML 文件中，更有利于系统的扩展或修改。不过前提是，我们需要为它

提供专门的 SQL 语句管理工具。

SQL 语句的使用无法避免，如何更好的应用 SQL 语句也无定论，但有一个原则值得我

们遵守，就是“应该尽量让 SQL 语句尽存在于数据访问层的具体实现中”。

当然，如果应用 ORM，那么一切就变得不同了。因为 ORM 框架已经为数据访问提供

了基本的 Select，Insert，Update 和 Delete 操作了。例如在 NHibernate 中，我们可以直接调

用 ISession 对象的 Save 方法，来 Insert（或者说是 Create）一个数据实体对象：

public void Insert(OrderInfo order)

{

ISession s = Sessions.GetSession();

ITransaction trans = null;

try

{

trans = s.BeginTransaction();

s.Save( order);

trans.Commit();

}

finally

{

s.Close();

}

没有 SQL 语句，也没有那些烦人的 Parameters，甚至不需要专门去考虑事务。此外，

这样的设计，也是与数据库无关的，NHibernate 可以通过 Dialect（方言）的机制支持不同的

数据库。唯一要做的是，我们需要为 OrderInfo 定义 hbm 文件。

当然，ORM 框架并非是万能的，面对纷繁复杂的业务逻辑，它并不能完全消灭 SQL 语

csAxp

河北工业大学——软件工程与理论整理：虾皮

句，以及替代复杂的数据库访问逻辑，但它却很好的体现了“80/20（或 90/10）法则”（也

被称为“帕累托法则”），也就是说：花比较少（10%-20%）的力气就可以解决大部分（80%-90%）

的问题，而要解决剩下的少部分问题则需要多得多的努力。至少，那些在数据访问层中占据

了绝大部分的 CRUD 操作，通过利用 ORM 框架，我们就仅需要付出极少数时间和精力来解

决它们了。这无疑缩短了整个项目开发的周期。

还是回到对 PetShop 的讨论上来。现在我们已经有了数据实体，数据对象的抽象接口和

实现，可以说有关数据库访问的主体就已经完成了。留待我们的还有两个问题需要解决：

1、数据对象创建的管理

2、利于数据库的移植

在 PetShop 中，要创建的数据对象包括 Order，Product，Category，Inventory，Item。在

前面的设计中，这些对象已经被抽象为对应的接口，而其实现则根据数据库的不同而有所不

同。也就是说，创建的对象有多种类别，而每种类别又有不同的实现，这是典型的抽象工厂

模式的应用场景。而上面所述的两个问题，也都可以通过抽象工厂模式来解决。标准的抽象

工厂模式类图如下：

例如，创建 SQL Server 的 Order 对象如下：

PetShopFactory factory = new SQLServerFactory();

IOrder = factory.CreateOrder();

要考虑到数据库的可移植性，则 factory 必须作为一个全局变量，并在主程序运行时被

实例化。但这样的设计虽然已经达到了“封装变化”的目的，但在创建 PetShopFactory 对象

时，仍不可避免的出现了具体的类 SQLServerFactory，也即是说，程序在这个层面上产生了

与 SQLServerFactory 的强依赖。一旦整个系统要求支持 Oracle，那么还需要修改这行代码为：

PetShopFactory factory = new OracleFactory();

修改代码的这种行为显然是不可接受的。解决的办法是“依赖注入”。“依赖注入”的功

能通常是用专门的 IoC 容器提供的，在 Java 平台下，这样的容器包括 Spring，PicoContainer

等。而在.Net 平台下，最常见的则是 Spring.Net。不过，在 PetShop 系统中，并不需要专门

的容器来实现“依赖注入”，简单的做法还是利用配置文件和反射功能来实现。也就是说，

csAxp

河北工业大学——软件工程与理论整理：虾皮

private static readonly string orderStategyPath =

ConfigurationManager.AppSettings["OrderStrategyAssembly"];

public static object LocateDALObject(string className)

{

string fullPath = dalPath + "." + className;

return Assembly.Load(dalPath).CreateInstance(fullPath);

}

public static object LocateDALOrderObject(string className)

{

string fullPath = orderPath + "." + className;

return Assembly.Load(orderPath).CreateInstance(fullPath);

}

public static object LocateOrderStrategyObject(string className)

{

string fullPath = orderStategyPath + "." + className;

return Assembly.Load(orderStategyPath).CreateInstance(fullPath);

}

//……

}

那么和所谓“依赖注入”相关的代码都可以利用 ServiceLocator 来完成。例如类 DataAccess

就可以简化为：

public sealed class DataAccess

{

public static PetShop.IDAL.IOrder CreateOrder()

{

return (PetShop.IDAL.IOrder)ServiceLocator. LocateDALOrderObject("Order");

}

通过 ServiceLocator，将所有与配置文件相关的 namespace 值统一管理起来，这有利于

各种动态创建对象的管理和未来的维护。

2.2.3、PetShop数据访问层之消息处理

在进行系统设计时，除了对安全、事务等问题给与足够的重视外，性能也是一个不可避

免的问题所在，尤其是一个 B/S 结构的软件系统，必须充分地考虑访问量、数据流量、服务

器负荷的问题。解决性能的瓶颈，除了对硬件系统进行升级外，软件设计的合理性尤为重要。

在前面我曾提到，分层式结构设计可能会在一定程度上影响数据访问的性能，然而与它

给设计人员带来的好处相比，几乎可以忽略。要提供整个系统的性能，还可以从数据库的优

化着手，例如连接池的使用、建立索引、优化查询策略等等，例如在 PetShop 中就利用了数

csAxp

河北工业大学——软件工程与理论整理：虾皮

据库的 Cache，对于数据量较大的订单数据，则利用分库的方式为其单独建立了 Order 和

Inventory 数据库。而在软件设计上，比较有用的方式是利用多线程与异步处理方式。

在 PetShop4.0 中，使用了 Microsoft Messaging Queue(MSMQ)技术来完成异步处理，利

用消息队列临时存放要插入的数据，使得数据访问因为不需要访问数据库从而提供了访问性

能，至于队列中的数据，则等待系统空闲的时候再进行处理，将其最终插入到数据库中。

PetShop4.0 中的消息处理，主要分为如下几部分：消息接口 IMessaging、消息工厂

MessagingFactory、MSMQ实现 MSMQMessaging以及数据后台处理应用程序 OrderProcessor。

从模块化分上，PetShop 自始自终地履行了“面向接口设计”的原则，将消息处理的接

口与实现分开，并通过工厂模式封装消息实现对象的创建，以达到松散耦合的目的。

由于在 PetShop 中仅对订单的处理使用了异步处理方式，因此在消息接口 IMessaging

中，仅定义了一个 IOrder 接口，其类图如下：

在对消息接口的实现中，考虑到未来的扩展中会有其他的数据对象会使用 MSMQ，因

此定义了一个 Queue 的基类，实现消息 Receive 和 Send 的基本操作：

public virtual object Receive()

{

try

{

using (Message message = queue.Receive(timeout, transactionType))

return message;

}

catch (MessageQueueException mqex)

{

if (mqex.MessageQueueErrorCode == MessageQueueErrorCode.IOTimeout)

throw new TimeoutException();

throw;

}

public virtual void Send(object msg)

{

queue.Send(msg, transactionType);

}

其中 queue 对象是 System.Messaging.MessageQueue 类型，作为存放数据的队列。MSMQ

队列是一个可持久的队列，因此不必担心用户不间断地下订单会导致订单数据的丢失。在

PetShopQueue 设置了 timeout 值，OrderProcessor 会根据 timeout 值定期扫描队列中的订单数

据。

MSMQMessaging 模块中，Order 对象实现了 IMessaging 模块中定义的接口 IOrder，同

剩余107页未读，继续阅读

yjiesun

粉丝: 60
资源: 6

微软PetShop4.0代码深度解析：架构、设计模式与数据库

PetShop4.0(微软宠物商店源代码)详解

微软宠物商店

微软的宠物商店源代码

浅说微软的宠物商店---三层架构

微软公司开发的宠物店系统4.0

ASP.NET宠物商店网页MyPetShop源代码

petshop(宠物商店)+V4.0源码文件

.Net 宠物商店

microsoft宠物店4.0，源代码+书打包下载

宠物商店-petshop

最新资源