设计模式在社区卫生服务系统中应用研究.docVIP

设计模式在社区卫生服务系统中应用研究 　　【摘 要】在软件开发过程中，面对不断变化的系统性能需求，软件系统往往过于脆弱和僵硬，不易维护，较难复用。在复杂的应用系统中，比如基于Web Service系统的应用中，如何使代码良好地组织起来，封装成类，将类组织成系统性的类库，这都需要开发人员在高于对象这一层面上来把握整个系统，设计模式就满足了这一需要。 　　【关键词】设计模式；卫生服务；数据库 　　在软件开发过程中，面对不断变化的系统性能需求，软件系统往往过于脆弱和僵硬，不易维护，较难复用。众多软件开发人员一直在不断总结实践经验，逐步形成了设计开发过程中的一种指导思想（即设计模式）。本文介绍通过社区卫生服务系统的开发实例，具体说明了在.NET环境下Web系统中设计模式的选择和运用方法。 　　1.工厂模式应用 　　1.1 工厂模式和抽象工厂模式概述 　　工厂模式的意图是定义一个用于创建对象的接口，让子类决定实例化哪一个类。抽象工厂模式的意图是提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。 　　1.2 模式的运用 　　在使用社区卫生服务系统的过程中，卫生局、医院、社区卫生服务中心/站三级间实现卫生数据共享，但社区卫生服务的门户网站、社区卫生服务系统中相关业务的操作却要求使用不同的数据库管理系统，比如Access、SQL Server。当系统的规模发生变化时，采用的存储手段就会发生相应变化，这时需要修改涉及数据存取操作的所有模块。如果我们假设都是采用数据库存储的，虽然不同的数据库管理系统都是基于能够使数据库使用简单的结构化查询语言，但在ADO.NET上的使用是不同的。在SQL Server上用的是System.Data.SqlClient命名空间下的SqlConnection、SqlCommand、SqlDataReader、SqlDataAdapter，而Access则要用System.Data.OleDb命名空间下的相应对象。这样不同的数据库在实现细节上的区别，不同数据库的替换给应用程序的使用、创建带来了一定的难度，并且潜在的创建了应用程序代码和数据访问代码之间的直接依赖性。 　　图1 User表增加用户结构图 　　如何在系统中争对不同业务使用不同的数据库，解除业务逻辑与具体数据库访问的耦合，工厂方法模式可以创建一个具体对象的接口，让子类决定实例化哪一个类，它可以实现客户不用了解哪个类要进行实例化。工厂方法模式实现代码（以User数据表中增加用户为例）结构图见图1。声明IUser接口的对象事先不需要知道是在访问数据库，但在运行时会很好地完成工作，实现业务逻辑与数据访问的解耦。 　　但随着更多数据提供者和输出类型的增加，一个基于工厂模式的类模型将成倍的增长。比如上述数据库中除User用户表外还有部门表，因此工厂模式在处理多于一个参数的问题就比较困难。本社区卫生服务系统的需求是要求系统能够在两种数据库之中选择一种数据库访问；系统数据的业务逻辑，即数据库的基本操作（包括添加、删除和修改等）仅具有行为而与数据无关。如果把具体的数据库访问看作一种“产品”，选择一种具体的数据库相当于由多个产品中的一个来配置，这点与抽象工厂模式的意图是相吻合的。因此，抽象工厂模式满足我们设计的要求，结构图见图2。 　　图2 抽象工厂模式在系统中的应用 　　抽象工厂模式的最大好处是易于交换产品系列，由于具体工厂类在一个应用中只需要在初始化的时候出现一次，这就使得改变一个应用的具体工厂变得非常容易，它只需要改变具体工厂即可使用不同的产品配置。本处中如果将访问Access数据库更改为访问Sql Server，我们只要将具体工厂AccessFactory更改为Sqlserverfactory就行了。抽象工厂模式的另一好处是，它让具体的创建实例过程与客户端分离，客户端是通过它们的抽象接口操纵实例，产品的具体类名也被具体工厂的实现分离，不会出现在客户代码中。本处客户端认识的只有IUser和IDepartment，至于它是用Sql Server来实现还是Access来实现就不知道了。这也正好符合面向对象的开放-封闭原则。 　　2.外观模式应用 　　2.1 外观模式概述 　　外观模式的意图是为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。 　　2.2 模式的使用 　　外观模式在实际开发中较多的运用于N层架构的应用程序。在设计初期阶段，基于MVC模式架构本系统，分成三个层次：系统层（数据访问层）、核心层（业务层）、应用层。这样在数据访问层和业务逻辑层、业务逻辑层和表示层的层与层之间建立Facade，为复杂的子系统提供一个简单拼接口，降低了客户程序与内部子系统间的耦合。 　　图3 系统架构图 　　在图3这个