数据库设计中使用设计模式

虽然看起来很美，但这却是一个美丽的谎言。

首先，在企业应用设计中，当选择了一个关系数据库系统后，在实施时企业将花费大量的资金购买数据库系统使用许可，而且数据库系统的实施、安装、日常维护也需要专门的人员来完成，更换数据库系统意味着企业的巨大损失，基本上不可能出现更换数据库系统的情况。

其次，大型数据库管理系统有着良好的设计和优化功能，而且不同的数据库系统有着自身的特点，很多特性是独有的，是不可移植的。采用 O/R 映射会损失数据库系统所特有的强大的功能。

第三，无论在进行系统设计时如何优化性能，O/R 映射最终都要转化为实际的数据库连接，进行实际的数据库操作，而这些任务是无法和数据库系统内部的存储过程、触发器的性能相比较的，而且即使通过连接池，也会增加数据库连接的负荷。

所以，良好的数据库设计仍然是企业应用中非常重要的步骤。

三 在数据库设计中应用 Façade 模式

当前系统设计中有大量的设计模式，Façade 设计模式更是深入人心。Façade模式描述为：“为子系统中的一套接口提供了一个统一的接口。Façade 定义了一个更高层次的接口，使子系统更容易使用。”在系统设计中，Façade 是应用最广泛的设计模式，利用 Façade 模式的思想把构成子系统的一套业务对象“包装”在Façade 接口中。这样，Façade对象作为客户端访问业务对象的拦截器，屏蔽了业务对象。客户端访问Façade对象来代替访问底层的业务对象，当一个客户端需要调用多个业务对象的方法时，它只需要进行一次粗粒度的远程方法调用，将请求送给Façade 对象, 再由Façade 对象通过本地方法调用，调用相应的业务对象，执行其方法。这样就减轻了网络负载，提高了系统性能。并且当底层业务对象的方法改动时，只需要修改 Façade 对象，而客户端可以保持不变。这就减少了客户端和业务对象之间的耦合度，同时客户端也不必管理事务的细节。如下图所示：

由 Façade 设计模式我们可以看出，如果将数据库系统认为是一个底层的业务系统，我们应该在设计数据库系统时隐藏底层的细节，而将所有对数据库进行的增、删、改、查询操作统一到一个 Façade 接口上来，这样在系统设计的过程中，所有与数据库系统打交道的业务组件无需关心底层的数据库存储方式，而是将底层的数据按照系统实体的方式展现出来，再通过 Façade 接口进行变换，将实际的实体提交给业务组件接口或者将实体持久化到真正的数据库表当中。

比如，在设计学生选课管理系统中，底层的数据表可能包括课程表、学生表、选课表以及成绩表，但对外表现出来的实体应该只有学生和课程两 个实体。然后可以通过一个存储过程暴露出来一个学生选课的功能，在业务组件中调用。同时应设计触发器，当插入选课信息到选课表的时候，在相应得成绩表中插 入相应的记录。而在业务组件端，仅仅看到底层数据库系统暴露出来的一个功能，即使数据库系统的设计发生变化，也不会影响业务组件的功能。

随着 SQL Server 2005 的发布，已经可以在 SQL Server 2005 中使用 .NET CLR 来进行数据库的编程，这对数据业务逻辑的封装提供了更好的支持。Oracle 已经支持 Java，并且也在进行 .NET CLR 的集成，IBM 的DB2 也有类似的功能。

采用Façade设计模式，能够较好的隔离底层数据库系统与业务组件之间的耦合，但物极必反，过度的使用存储过程也可能带来不必要的设计麻烦。在数据库设计中，适当的暴露底层的视图也是一种良好的设计风格。一个全面的、良好的设计才是系统成功的保证。