数据层（Database）
.NET Petshop的数据库并不是十分的庞大，总共有12个用户表和23个存储过程。Petshop数据库里面存储的是用户数据，帐号数据，产品数据，用户配置数据，订单数据，库存数据以及供应商的数据。应用程序访问数据库的数据并不是直接的与数据库表打交道，而是通过存储过程的运行来获取所需要的数据。这样的设计有一个好处就是，避免了频繁的表操作，而通过运行在服务器端的存储过程可以极大的提高运作效率和提升访问数据的速度，同时也很好的屏蔽了数据库表的逻辑，使得数据库访问变成了数据库提供的服务访问。当然，也有人指责说这些存储过程迁移性是值得怀疑的。 下面我将通过表格把这些数据库的基本表列出来（见表1），并一一做说明，希望对大家深入的理解有帮助。
表名称 备注信息
Account 基本用户信息。
BannerData 存储的是系统界面的banner图片的设置信息。
Category 宠物的类别目录表（比如鱼类，狗类等等）。
Inventory 宠物产品的存货信息。
Item 单个产品的详细信息。
LineItem 订单的每一项的详细信息，包括产品名称和数量，价格等。
Orders 用户购物的订单，一个订单可以包括多项LineItem
OrderStatus 订单的状态 Product 宠物的产品列表，一条Product可能包括多个Item Profile 用户配置表，用于记录他们的favorites。
Signon 用户帐号登陆表，因为常用，故从Account独立出来。
Supplier 供应商信息。
技巧：其实对于从事过数据库建模和设计的人都知道，得到上面的数据库模型图形并不是一件很困难的事情。正如我们前面提到的一样，我们可以用Visio做工程反转就可以得到上面这么美观的设计模型图了。同时，我们也可以在模型图中做修改设计，可以马上应用到你的物理数据库，使其保持同步。
说完了基本的数据库表，接下来我们看看存储过程。用微软的话说，只有设计称存储过程，才算是”cleaner separation of code from the middle-tier”，我个人觉得这样做是很好的。同样的，我把它列在一个表格里（表2）。
|
存储过程名称 |
备注信息 |
|
upAccountAdd |
增加一个帐号。 |
|
upAccountGetAddress |
获取用户的地址，主要用于下订单时注册地址与送货地址不一。 |
|
upAccountGetDetails |
获取帐号的详细信息。 |
|
upAccountLogin |
用户登陆验证。 |
|
upAccountUpdate |
更新用户帐号。 |
|
upCategoryGetList |
获取某个类别的产品列表。 |
|
upInventoryAdd |
增加指定的项到存活信息。 |
|
upInventoryGetList |
获取存货列表。 |
|
upItemAdd |
增加一项产品。 |
|
upItemGetDetails |
获取指定产品项的详细信息。 |
|
upItemGetList |
获取某一特定类别的产品的具体项目列表。 |
|
upItemGetList_ListByPage |
功能与上同，但是分页获取数据。 |
|
upOrdersAdd |
增加一项订单。 |
|
upOrdersGet |
获取某一订单的信息。 |
|
upOrdersGetDetails |
获取某一订单的详细信息。 |
|
upOrderStatusGet |
获取订单的状态。 |
|
upProductAdd |
增加一类别产品。 |
|
upProductGetList |
返回某类产品的列表。 |
|
upProductGetList_ListByPage |
与上同，但是分页获取结果数据。。 |
|
upProductSearch |
产品搜索。 |
|
upProductSearch_ListByPage |
与上同，但是翻页获取结果数据。 |
|
upProfileGetBannerOption |
Banner的配置信息。 |
|
upProfileGetListOption |
获取用户配置信息。 |
表2：petshop存储过程列表
在这些存储过程里面使用了SQL Server2000的OpenXML的特性来代替传统的行集结果，使用在非常频繁的数据访问操作，可以减轻系统的负担。
好了，petshop的Datatier就说到这里了，在后面的文章我会就一个数据访问的实例再次解说存储过程的执行。接下来我将就中间层做介绍了。