技术框架

一、设计思路1.1一体化一体化是系统最基本的建设原则。只有真正实现了一体化才能真正合理地利用企业资源，实现信息高度共享，为企业管理创造效益。一体化可以从以下几个方面来理解：1、数据的一体化1）必须站在全局角度进行数据结构的分析和设计，充分考虑数据的完整性和共享性以及相关性；2）数据集中存放和管理。2、体系框架一体化按一体化思想构造软件体系结构，合理建立对象模型。3、应用的一体化业务相互关联，协同工作，本身就是一体化的。所以构造相关应用时必须考虑一体化的问题。4、与其他系统的集成必须与其他管理系统进行集成，处理好与它们的接口，保证整个的一体化。1.2平台化建立统一的系统基础平台，以达到如下目的：1、便于系统升级扩充；2、便于整合其他系统；3、有利于系统稳定性；4、减少系统研发工作量，提高研发工作效率，缩短项目实施周期。1.3标准化系统开发管理过程需按照IT行业规范进行的，采用CMM的思想进行精细化管理，不管是软件结构、功能、界面、文档、过程有规可寻。1.4开放性系统必须坚持开放性原则。系统肯定面临整合目前现有其他系统和升级改造以及未来接入其他系统的问题。而解决这些问题的根本做法就是建设开放的软件体系结构。1.5方便实用实用性指的是系统是否能切合用户的实际需要。是否符合操作人员和管理人员工作习惯。是否符合行业的管理规范。1.6采用先进的管理思想建立合理的开发流程及团队成员密切的合作;建立共同的工作框架、规范;学习一些成功开发过程、分析方法、设计思想、体系结构、设计模式等.学习合理统一开发过程（RUP）的一些实践;1.7先进的软件开发技术采用先进的基于java的J2EE技术，构造稳定的，开放的，安全的技术平台。采用B/S软件体系结构。采用Spring,EJB,Hibernate,WebWork2等成熟软件框架。采用UML，按照RUP方法管理开发过程。其结构图如图1所示。图1平台结构设计图系统基础架构是整个平台的基础，处于整个系统的最底层，其它的业务系统都构建在它的上面，它为业务系统提供服务，基础架构包括视图控制层，业务逻辑层，数据持久层等。系统基础架构的设计和实现必须满足稳定性，安全性，高效性和可扩展性等技术要求。在系统基础架构的设计和实现中我们引进了面向切面（AOP）的编程技术、MVCWEB编程技术和O/RMapping技术等多种先进的IT技术；同时我们对系统采用了多层结构，整个基础架构分为表示层，表示层控制层，业务逻辑层，数据持久化层等，并使层与层之间的干扰降到最低，保证了系统的稳固性、高效性和高可扩展性。系统的组件图如图2所示。客户端（Browser）数据库XML文件O/RMapping业务逻辑实现调用层接口数据访问层业务逻辑层视图层视图控制组件actionDAO实现DAO接口AjaxServiceJSP,Velocity,FreeMarker,JasperReportsJavaScript图2系统组件图保证系统有高可扩展性的相当有效的方法是实现组件化。将系统中的各个部分通过组件的方式进行组织、实现，以方便对组件进行重用和替换。系统中每个组件都包含一个服务接口（BizService）和至少一个服务实现体（BizServiceImp）。通过接口来隔离组件的使用者和实现者。对组件的创建使用JAVA的反射机制，借助反射，组件的创建过程可以被配置，组件的实现也可以被灵活的替换。二、技术层总体设计2.1系统分层结构2.1.1数据访问层在Java发展的初级阶段，直接调用JDBC几乎是数据库访问的唯一手段。随着近年来设计思想和Java技术本身的演化，出现了许多JDBC的封装技术，这些技术为我们的数据库访问层实现提供了更多的选择。这些框架以优良的设计大大提高了数据库访问层的开发效率，并且通过对数据访问中各种资源和数据的缓存调度，实现了更佳的性能。持久层框架封装了数据库持久层的大多数技术细节，如事务管理，数据库连接、SQL生成等。目前的持久层框架，建立在面向对象的设计思想之上。ORM（ObjectRationalMapping）几乎是目前主流持久层框架的基本特性。ORM为系统设计提供了更加自然的实现方式。我们可以通过ORM将系统中的DomainObject自动映射到各个数据库表，从而编码中只需关心Object的相关属性。持久层框架提供了优秀的性能优化机制，如内置的数据库连接池支持，PreparedStatement缓存，数据缓存等。这些优化机制的综合使用大大提升了系统性能。更重要的是，由于设计上更加全面的考量，这些机制对于上层构架完全透明，我们无需关心其中复杂的实现细节即可享用其所带来的性能提升。基于Java的跨平台特性，我们的系统可以在不同操作系统之间切换。但由于数据库之间的差异，系统在数据库平台之间的迁移却遇到了阻力。使用成熟持久层框架，由于设计上的良好隔离，从而提供了对不同数据库的良好支持，我们只需简单的修改其配置参数，即可实现底层数据库的切换。使用成熟持久层框架，对于快速移植也很有好处。通过对多种实体层方案的评估，采用现有的成熟框架Hibernate作为O/RMapping的实现，基于对象关系映射（O/RMapping）模型的架构采用Hibernate架构。Hibernate架构是目前使用最多，最成熟的O/RMapping实现之一。Hibernate在2003年末被JBoss组织收纳，成为从属于JBoss组织的子项目之一，并逐渐发展成Java持久层事实上的标准。在连接业务逻辑和数据层之间使用了很薄的一层DAO封装层，这里采用Spring的hibernate操作模版，同时对业务逻辑层暴露事务处理的接口。2.1.2业务逻辑层8:someDAOMethod():Action:Action:BizAgent:BizAgent:SessionFacade:SessionFacade:BizServiceImp:BizServiceImp:DAOServiceImp:DAOServiceImp1:getService(BizService.class)2:BizServiceImp3:someBusinessMethod()4:invoke()5:someBusinessMethod()6:getLocalService()7:DAOServiceImp9:ListofBizObject业务逻辑层中使用了spring的IOC来管理业务逻辑层的业务组件，方便配置，降低偶合。在业务逻辑层的出口处采用AOP模式，统一管理出口，同时通过AOP统一处理了事务、权限、异常、日志等问题。在实现AOP时，采用了普通javaBean实现和EJB的SessionBean来实现，通过配置文件可以方便切换实现方式，这样可满足各种运用环境。即可以用于硬件环境较差、用户数少的应用环境，也可以适用于分布式、强负荷环境。2.1.3表示层表示层采用现成熟的表示层框架WebWork2来实现。WebWork是由OpenSymphony组织开发的，致力于组件化和代码重用的拉出式MVC模式J2EEWeb框架。WebWork目前最新版本是2.1，现在的WebWork2.x前身是RickardOberg开发的WebWork，但现在WebWork已经被拆分成了Xwork1和WebWork2两个项目。Xwork简洁、灵活功能强大，它是一个标准的Command模式实现，并且完全从web层脱离出来。Xwork提供了很多核心功能：前端拦截机（interceptor），运行时表单属性验证，类型转换，强大的表达式语言（OGNL–theObjectGraphNotationLanguage），IoC（InversionofControl倒置控制）容器等。WebWork2建立在Xwork之上，处理HTTP的响应和请求。WebWork2使用ServletDispatcher将HTTP请求的变成Action(业务层Action类),session（会话）application（应用程序）范围的映射，request请求参数映射。WebWork2支持多视图表示，视图部分可以使用JSP,Velocity,FreeMarker,JasperReports，XML等。2.2组织架构设计采用组织－部门－人员的组织架构，通过长期的实践证明这样可以充分满足各种复杂需求。其中组织是顶级机构，又可称为公司。部门这是各个组织下的部门，如信息部，研发部等等。一个人只能属于一个部门，一个部门只能属于一个组织。2.3系统功能模块划分2.4权限设计2.4.1结构设计权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真。针对不同的应用，需要根据项目的实际情况和具体架构，在维护性、灵活性、完整性等N多个方案之间比较权衡，选择符合的方案。权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。相当多的权限问题因其极其独特而不具通用意义，它们也能被理解为是“业务逻辑”的一部分。比如，要求：“合同资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”。这既可以认为是一个权限问题，也可以认为是一个业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设计之中不予过多考虑。当然，权限系统的架构也必须要能支持这样的控制判断。或者说，系统提供足够多但不是完全的控制能力。即，设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。需要再次强调的是，这里表述的权限系统仅是一个“不完全”的权限系统，即，它不提供所有关于权限的问题的解决方法。它提供一个基础，并解决那些具有“共性”的(或者说粗粒度的)部分。在这个基础之上，根据“业务逻辑”的独特权限需求，编码实现剩余部分(或者说细粒度的)部分，才算完整。回到权限的问题公式，通用的设计仅解决了Who+What+How的问题，其他的权限问题留给业务逻辑解决。通过角色来划分权限，角色通过组织来进行分类。通过把权限赋予角色，再把角色赋予人员，而使人员具有操作权限。通过组织来划分角色，这样可以使得不同组织下的同名角色拥有不一样的权限，而且可以方便控制角色的组织与所在登陆系统组织的关系。考虑到系统中任何一个动作都会调用权限接口来判断权限，这里权限－角色－人员对应关系采用简单关联（权限－角色，角色－人员），而不使用复杂的关联（权限－角色、权限－人员，角色－人员），这样在配置上也许缺少一定的灵活性，但考虑性能问题优先，并且使配置清晰明了，这里选择关系相对简单的前者。同时在用户登陆时，把相应的权限信息保存在cache中，用户退出时清除cache，这样减少了数据库的访问压力，进一步提高了系统运行效率。2.4.2权限控制权限是在哪一个层次上的定义呢？将permission定义在“业务逻辑方法”级别可能会比较合适。比如，发布、购买、取消。每一个业务逻辑方法可以意味着用户进行的一个“动作”。这些操作更高级的概念可能是信息发布子系统，商品销售子系统，订单管理子系统，在这个级别上定义permission在某些情况下或许也是合理的，但显然不够灵活。在更低的级别上，或许可以设想在某些表(或者信息字段)的CRUQ(增删改查)动作上定义permission概念。再通过这些权限的组合与交叉，用更少的permission表述复杂的操作。这往往是很多程序员最直接的想法。初一看，似乎简单明了，而且好像能够简化维护工作。但，实际上，这样的定义方式不仅过于繁琐，仅就功能而言也是不足取的。一方面，这样的定义方式不足够完成更复杂的权限辨别。比如，一个购买操作，就可能意味着对系统中N个表的检索，更新，乃至删除。在这样的情况下，对多个表的permission的组合将会极其令人痛苦，因为基本上，所有可能用到的操作都必须开放给每一个可能要进行这种操作的用户。另一方面，这样的方式因为将权限深入到了系统的数据访问层，使用起来将极其不便。也就是说，在这样的定义模式下，每一个数据访问方法都必需要知道当前的操作者是谁——在数据访问逻辑中必需