petshop4.0详解之二(数据访问层之数据库访问设计)VIP免费

petshop4.0 详解之二（数据访问层之数据库访问设计） 在系列一中，我从整体上分析了PetShop 的架构设计，并提及了分层的概念。从本部分开始，我将依次对各层进行代码级的分析，以求获得更加细致而深入的理解。在PetShop 4.0 中，由于引入了ASP.Net 2.0 的一些新特色，所以数据层的内容也更加的广泛和复杂，包括：数据库访问、Messaging、MemberShip、Profile 四部分。在系列二中，我将介绍有关数据库访问的设计。 在PetShop 中，系统需要处理的数据库对象分为两类：一是数据实体，对应数据库中相应的数据表。它们没有行为，仅用于表现对象的数据。这些实体类都被放到 Model 程序集中，例如数据表 Order 对应的实体类 OrderInfo，其类图如下： 这些对象并不具有持久化的功能，简单地说，它们是作为数据的载体，便于业务逻辑针对相应数据表进行读/写操作。虽然这些类的属性分别映射了数据表的列，而每一个对象实例也恰恰对应于数据表的每一行，但这些实体类却并不具备对应的数据库访问能力。 由于数据访问层和业务逻辑层都将对这些数据实体进行操作，因此程序集 Model 会被这两层的模块所引用。 第二类数据库对象则是数据的业务逻辑对象。这里所指的业务逻辑，并非业务逻辑层意义上的领域（domain）业务逻辑（从这个意义上，我更倾向于将业务逻辑层称为“领域逻辑层”），一般意义上说，这些业务逻辑即为基本的数据库操作，包括Select，Insert，Update 和Delete。由于这些业务逻辑对象，仅具有行为而与数据无关，因此它们均被抽象为一个单独的接口模块IDAL，例如数据表 Order 对应的接口 IOrder： 将数据实体与相关的数据库操作分离出来，符合面向对象的精神。首先，它体现了“职责分离”的原则。将数据实体与其行为分开，使得两者之间依赖减弱，当数据行为发生改变时，并不影响Model 模块中的数据实体对象，避免了因一个类职责过多、过大，从而导致该类的引用者发生“灾难性”的影响。其次，它体现了“抽象”的精神，或者说是“面向接口编程”的最佳体现。抽象的接口模块IDAL，与具体的数据库访问实现完全隔离。这种与实现无关的设计，保证了系统的可扩展性，同时也保证了数据库的可移植性。在 PetShop 中，可以支持 SQL Server 和 Oracle，那么它们具体的实现就分别放在两个不同的模块SQLServerDAL、OracleDAL 中。 以 Order 为例，在 SQLServerDAL、OracleDAL 两个模块中，有不同的实现，但它们同时又都实...