软件系统开发中的组件框架技术研究、设计和应用

3、组件框架设计和开发

3.1、组件框架设计的方法

实践中，组件框架设计应该采用分层设计模型，组件采用递归结构。每个框架不能依赖其他框架而存在，应该能够独立开发和部署。组件和组件之间，组件和框架之间只能通过API通讯。

将组件框架应该再细分成表现层框架、业务层框架、数据层框架、公共服务框架、基础框架、系统框架和与业务系统密切相关的业务框架等构成，除了具体的业务框架外，其他框架必须优先选择比较成熟的产品和免费框架。

组件设计过程中要精心定义组件的创建方法、组件标识符、接口规范和组件的功能等要素。组件多采用定义了良好接口的工厂组件创建，而工厂组件则由系统函数或系统对象创建。组件标识符主要采用GUID、接口名称、其他特定的字符串等表示，它是客户程序使用组件的逻辑名，应用系统在运行过程中，由容器将其与组件的具体实现映射。接口规范多用函数和抽象类的形式表现。组件的内部结构如图2所示。有组件工厂、组件服务提供者、抽象服务等。抽象服务是实现组件接口的一个抽象类，其目的是为了简化应用程序对组件的编码。应用程序只要继承该抽象类即可满足接口规范需要，而把精力集中到核心功能的实现上。

图2

组件采用组件工厂、组件服务提供者、抽象服务等内部设计模式，可以极大地降低组件与使用该组件的客户程序的耦合度，客户程序只要使用组件的逻辑名，通过容器提供的名称服务得到组件接口即可利用组件提供的功能，而不必关心组件的内部具体实现，组件具有非常好的封装性。

系统函数或系统对象、组件标识符、接口规范一旦定义则不能轻易改变，否则，就会造成整个框架体系和使用此框架的所有应用程序的修改。这里唯一需要改变的是组件的功能，它由具体的应用程序实现。

框架设计需要解决的问题还包括容器规范、组件规范、容器提供服务和部署描述符设计、类装入方案等。部署描述符定义容器和组件之间的协议，并封装组件之间的相互关系。部署描述符要优先选择XML语言表达。

3.2、设计组件框架的原则和评价标准

当一个组件框架设计完成后，应该按照开闭原则、依赖倒转原则、接口隔离原则等对其进行评价，检查和评价整个系统的可维护性和可复用性。

按照开闭原则，要检查设计的组件框架是否满足对扩展开发，而对修改关闭，即整个框架在扩展其功能时，应当是在不修改代码的前提下便可，换言之，源代码不修改，框架行为就可改变。要实现开闭原则，组件的抽象化是关键，实践中，检查在框架中是否容易加入“即插即用”的组件便是经验之一。

依赖倒转原则，就是要检查系统要依赖于抽象，而不是依赖于具体的实现。即客户端编程要依赖于抽象耦合，而不是具体耦合，要针对接口编程，而不是针对实现编程。具体的讲，就是看一个组件在其逻辑名称、接口不改变的情况下，修改其对象名称、类名称以及具体实现的情况下，客户程序是否需要修改。如果不是，则该框架不符合依赖倒转原则，可扩展性和可维护性存在问题。

通过接口隔离原则，可以检查一个组件是使用了多个专门的接口，还是使用单一的总接口进行编程。如果使用过于臃肿的接口，便存在接口污染。一个接口应当简单地只代表一个角色，而不是多个角色。如果组件涉及多个角色，那么每一个角色应当由一个特定的接口代表。也就是说，一个接口其中的函数数量应该越少越好。

符合上述原则的框架，基本上是在高层次实现了系统的复用，也是一个易于维护的系统，才值得投入人力和物力去编码，否则，该框架的生命周期不会太长，系统开始修改之时，可能也是其终结之日。

4、组件框架的选择和应用

选择组件框架设计模式开发信息系统已经成为当今缩短系统开发周期、提高稳定性、降低维护成本、延长生命周期的主流技术。目前，从运行环境、基础框架到专业的业务实现方面均有可资利用的成熟框架。我们在开发专业的应用系统时，无论从时间，还是资金方面考虑，都有必要充分利用现成的框架体系结构。选择框架应该综合考虑，跨平台、成熟度、稳定性和规范程度等多种因素。

（1）在容器选择方面，对于需要跨平台的企业级应用，应该优先考虑Websphere、Weblogic等支持J2EE构架的商用服务器端系统。而对于访问量低、并发用户不多的应用则可以选择Tomcat、Jboss、Jfox等开源项目作为系统运行环境，其性价比非常高。对于图形界面要求高的系统也可以选择.NET作为系统运行容器。而开发客户端应用程序首选Eclipse、Netbeans等作为系统的运行容器。Eclipse和Netbeans都是用Java语言开发的基于插件的体系结构，源码开发，成熟度较高。前者目前主要用于集成C++、Java编译器和其他开发工具，以及整合工作流、系统部署等方面，得到了IBM等大公司的支持。后者主要的应用集中在Java应用程序方面的开发。它们的可扩展性和可维护性都比较高，作为客户端应用程序的容器非常理想，应用的部署和运行比较简单，比如Eclipse只要将开发好的插件压缩封装成jar包，拷贝到系统规定的Plugins目录中便可，几乎不需要什么配置，在因特网中有许多开源的插件可供使用，应用涉及的范围很广。

（2）对于基础框架，可供选择的框架有PicoContainer、Spring和Avalon等。PicoContainer框架基于注册模式封装组件关系。而Spring框架其组件均利用Java beans实现，支持国际化、事件监听、事务管理，支持内省反射和AOP技术，易于和Mail、JNDI及数据库集成。对于Avalon框架，定义的组件接口非常简单，比如，组件创建、销毁、服务等接口，函数单一，结构清晰，充分体现了接口隔离原则，实现起来均比较容易。这些框架属开源项目，帮助文档较多，有许多人在研究和开发，它们均可脱离J2EE应用服务器运行，是开发专用业务系统比较理想的基础框架。

（3）在系统的表现层，如果系统需要单点登录、能够集成其他应用和服务、提供个性化支持，则应该选择支持Ｐortal规范的框架作为表现层的容器。此类框架如  Weblogic Portal、IBM Websphere Portal等，其特点是系统比较成熟，但结构复杂，投资成本较高，页面的美工设计不够灵活，系统集成需要比较多的编程经验和编程知识，不适合系统维护力量较低，页面设计频繁改动的应用。免费的Ｐortal框架典型的是Jetspeed，其Portal组装使用PSML语言，结构良好，运行在Turbine框架之中，Turbine将页面视图划分为页面、布局、屏幕、导航和动作等组件，并利用属性文件封装，使用Velocity模板语言，表现和业务代码分离。Jetspeed和前述商用Portal相比，缺乏好的开发工具支持，比较适合技术力量雄厚的部门使用。

表现层还可以选择的一个框架就是Struts，其在许多系统开发中得到了广泛的支持。该框架有控制器组件、视图组件和插件等组成。完全基于MVC模式设计，组件关系利用符合XML规范的配置文件封装，并提供了控制器、插件等许多扩展点，支持国际化、无编程数据验证、配置性异常处理以及多应用部署，能够和EJB、SOAP集成，其中内置了几乎所有的HTML标签，和Tiles模板框架配合使用，能够开发出高质量的应用系统。

（4）在模型层和数据层，主要是将数据的概念模型映射成设计模型，大多数框架都是将和数据库通讯的JDBC驱动程序通过二次封装，屏蔽掉不同数据库之间在SQL语言方面的差异，减少开发人员用数据库系统实现数据持久化方面的知识，并为上层模块提供比较统一的系统调用。可资选择的框架除了著名的实体EJB外，还有如Hibernate、Toplink和Torque等轻量级的持久化框架，其实现大同小异，基本都是通过XML配置文件将数据概念模型中的字段映射成Java语言中的对象属性，编程人员一般只要按照DAO设计模式，用Java语言定义业务对象BO，并完成数据映射配置文件便可，减少了通过JDBC直接使用SQL语言的复杂度。此类框架的选择，一般应考虑支持目前的主流数据库系统，如Oracle、SQL Server等。对于小型的应用还要考虑支持MYSQL、PostgreSQL等免费的数据库管理系统。这样更换数据库时，只要修改数据映射配置文件、数据库驱动程序和数据源配置便可，整个系统框架不用修改，提高了系统的稳定性和可维护性。

（5）在系统日志管理方面选择Log4j、XML解析框架选择Degester，工作流引擎选择OFBIZ、SHARK、OBE或JBPM等，内容管理选择基于管道技术的COCOON这些开源框架，均会缩短编码时间，提高系统的开发效率。

总之，在信息系统的开发中，重点应该放在规划业务系统，开发业务型框架，定义和实现信息系统本身的业务逻辑上，而对于所有业务系统通用的功能和逻辑应优先选择现有框架的有效组合实现，以期达到事半功倍的效果。

查看本文来源