PetShop数据库访问层设计如何优化以适应长尾词查询需求？

本文共计3145个文字，预计阅读时间需要13分钟。

PetShop 数据访问层设计概述

整体上，我对PetShop的架构进行了分析，并提出了分层概念。从局部开始，我将依次对每一层进行代码级别的分析，以获得更详细的了解。

二、PetShop数据访问层之数据库访问设计

　　在系列一中，我从整体上分析了PetShop的架构设计，并提及了分层的概念。从本部分开始，我将依次对各层进行代码级的分析，以求获得更加细致而深入的理解。在PetShop 4.0中，由于引入了ASP.Net 2.0的一些新特色，所以数据层的内容也更加的广泛和复杂，包括：数据库访问、Messaging、MemberShip、Profile四部分。在系列二中，我将介绍有关数据库访问的设计。

　　在PetShop中，系统需要处理的数据库对象分为两类：一是数据实体，对应数据库中相应的数据表。它们没有行为，仅用于表现对象的数据。这些实体类都被放到Model程序集中，例如数据表Order对应的实体类OrderInfo，其类图如下：

　　这些对象并不具有持久化的功能，简单地说，它们是作为数据的载体，便于业务逻辑针对相应数据表进行读/写操作。虽然这些类的属性分别映射了数据表的列，而每一个对象实例也恰恰对应于数据表的每一行，但这些实体类却并不具备对应的数据库访问能力。

　　由于数据访问层和业务逻辑层都将对这些数据实体进行操作，因此程序集Model会被这两层的模块所引用。

　　第二类数据库对象则是数据的业务逻辑对象。这里所指的业务逻辑，并非业务逻辑层意义上的领域（domain）业务逻辑（从这个意义上，我更倾向于将业务逻辑层称为“领域逻辑层”），一般意义上说，这些业务逻辑即为基本的数据库操作，包括Select，Insert，Update和Delete。由于这些业务逻辑对象，仅具有行为而与数据无关，因此它们均被抽象为一个单独的接口模块IDAL，例如数据表Order对应的接口IOrder：

　　将数据实体与相关的数据库操作分离出来，符合面向对象的精神。首先，它体现了“职责分离”的原则。