Jdon框架：Jdon框架核心设计架构

Jdon框架核心设计架构

架构设计

由于整个框架中中组件基于Ioc实现，组件类之间基本达到完全解耦。

从上图中可以看出，任何JavaBeans组件只要在XML配置文件（container.xml aspect.xml和jdonframework.xml）中配置，由容器装载机制注册到Ioc 容器中，这些组件的客户端，也就是访问者，只要和微容器（或者组件的接口）打交道，就可以实现组件访问。

因此，本框架中每个功能块都可从框架中分解出来，单独使用它们。用户自己的任意功能块也可以加入框架中，Jdon框架成为一种完全开放、伸缩自如的基础平台。

运行原理图：

当客户端请求产生时，首先将访问目标服务参数包装在userTargetMetaDef对象中，该对象访问位于HttpSession中的动态代理实例，被动态代理将目标服务肢解成Method和方法参数Args，然后被拦截器拦截，最后达到目标服务实例，当然，有的拦截器可能就此完全拦截（堵住去路，如PoolInterceptor），目标服务实例是事先被注册到容器中的，在被访问时，缺省情况是每次访问产生一个新的目标服务实例。

Jdon容器如图是被保存在Servlet容器的ServletContext中的。

包结构

Jdon框架有下列包名组成：

AOP : 表示AOP相关功能的类，其与bussinessproxy包关系最紧密，两者是系统的核心包。

Bussinessproxy：与动态代理、目标服务相关的类。

Container：实现将组件装载入容器，这是与Ioc 微容器相关的类，缺省使用了PicoContainer，但是可以替换的。包括容器的组件注册、配置读取、组件访问等功能。以上三个包可从Jdon框架中独立出来。

Controller: 这是一些基础功能类、以及和应用相关类的功能包，该包是Container的客户端。

Model：这是和数据模型增删改查（CRUD）。批量查询、缓存优化等相关功能的类。

Security：这是和用户注册登陆相关功能类，

Servicelocator：这是和EJB 运行定位相关的类

Strutsutil：与Struts相关类，前面Model包中各种功能必须通过具体表现层技术实现。

Util：一些工具类。

container包

Container包主要是负责容器管理方面的功能，其他包中的组件都被写入配置文件container.xml、aspect.xml和jdonframework.xml中，而container包主要负责与这些配置文件打交道，从配置文件中获得其他包的组件，向容器中注册，并启动容器。

主要一个接口是ContainerWrapper， ContainerWrapper有两个主要方法：向容器注册组件；从容器查询获得组件。

ContainerWrapper接口的缺省实现是PicoContainerWrapper和VisitorContainerWrapper两个子类，如下图：

PicoContainerWrapper使用了著名的PicoContainer实现（http://www.picocontainer.org），ContainerWrapper接口主要从其抽象出来。

访问者模式

VisitorContainerWraper是观察者模式的实现，传统观察者模式中，对于Visitor角色一般有下面多个访问不同被访问者的方法：

visitAcomponent();

visitBcomponent();

…..

由于Acomponent、Bcomponent这些类已经注册到容器，因此，通过容器可以直接直接实现不同组件的访问，只需通过下面一个方法实现：

public ComponentVisitor getComponentVisitor(){

return new ComponentOriginalVisitor(this);

}

而访问者Visitor则可以节省为单一方法即可：

visit(XXX xxx);

使用访问者模式的原因：主要为了实现缓存，提高一些组件运行性能，如果一些组件每次访问时，都需要new，例如Proxy.newInstance如果频繁反复运行，将是十分耗费性能的，因此，使用缓存尽量避免每次创建将提高系统的运行性能。

Visitor有两个子类实现：ComponentOriginalVisitor和HttpSessionProxyVisitor，这里又使用了装饰者模式，Decoratee 是ComponentOriginalVisitor；而Decorator是HttpSessionProxyVisitor，HttpSessionProxyVisitor是HttpSessionBindingListener，也就是说，我们使用了HttpSession作为缓存机制，HttpSession的特点是以用户为Key的缓存，符合♂的缓存机制，当然，我们以后也可以使用更好的缓存机制替换HttpSession，替换了HttpSession根本不必涉及到其他类的更好，因为这里使用模式实现了彻底的解耦。

访问者模式另外一个重要角色：Visitable，它则是那些运行结果需要缓存的组件必须继承的，注意，这里有一个重要点：不是那些组件本省生成需要缓存，而是它的运行结果需要缓存的。继承Visitable这些组件事先必须注册在容器中。

目前Visitable有两个子类：

* @see com.jdon.bussinessproxy.dyncproxy.ProxyInstanceFactoryVisitable

* @see com.jdon.bussinessproxy.target.TargetServiceFactoryVisitable

前者主要是动态代理的创建，因为Proxy.newInstance频繁执行比较耗费性能，第一次创建后，将动态代理实例保存在httpSession中，当然每个Service对应一个动态代理实例。

TargetServiceFactoryVisitable主要是为了缓存那些目标服务的实例，目前这个功能没有激活，特殊情况下才推荐激活。

容器的启动

容器启动主要是将配置文件中注册的组件注册到容器中，并启动容器，这涉及到container包下Config和Builder等几个子包。

Config包主要负责从container.xml和aspect.xml读取组件；

Builder包主要负责向ContainerWrapper注册这些组件，注册过程是首先从基础组件（container.xml）开始，然后是拦截器组件(aspect.xml)，最后是用户的服务组件(jdonframework.xml)。

容器的生命周期

容器启动后，容器本身实例是放置在Web容器的ServletContext中。

容器启动并不是在应用系统部署到Web容器时就立即启动，而是该应用系统被第一次访问时触发启动，这个行为是由ContainerSetupScript的startup触发的，而startup方法则是由ServletContainerFinder的findContainer触发。

当应用系统从Web容器中销毁或停止，Jdon框架容器也就此销毁，最好将你的组件中一些对象引用释放，只要继承Startable，实现stop方法即可。

容器的使用

客户端访问组件必需通过容器进行，这个过程分两步：

从Web容器中获得框架容器ContainerWrapper实例。

从ContainerWrapper容器中查询获得组件实例，有两者实例方式：单例和多例。

关于具体使用方式可见前面章节“如何获得POJO实例”等。

这个容器使用过程是通过finder包下面的类完成，主要是ServletContainerFinder类，ComponentKeys类保存中一些container.xml中配置的组件名称，这些组件名称可能需要在框架程序中使用到，这就需要引起注意，这个类中涉及的组件名称不要在container.xml中随意改动（当然这个类在以后重整中争取去除）。

com.jdon.controller.WebAppUtil是专门用于客户端对微容器的访问，这个客户端目前是Http客户端，主要方法：

public static Object getService(String name, HttpServletRequest request)

这是最常用的从容器中获得服务实例的方法。需要HttpServletRequest作为客户端，Jdon框架将来会提供作为Application客户端调用的专门方法。

public static Object getComponentInstance(String name, HttpServletRequest request)

这是获得组件实例的方法。

public static String getContainerKey()

通过获得容器保存在ServletContext中的Key。

从容器内部访问容器

上节“容器的使用”是指从容器外部（客户端）如何访问和使用容器，如果当前客户端是在容器内部，例如需要在一个Service服务类中访问容器的缓存机制等，该如何访问？

使用com.jdon.container.finder. ContainerCallback，同时，该服务POJO类以ContainerCallback作为构造参数，当该POJO服务类注册到容器中时，容器的Ioc特性将会找到事先以及注册的ContainerCallback类。

通过ContainerCallback获得ContainerWrapper容器实例，然后通过ContainerWrapper下面两个方法：

public Object lookup(String name);

从容器中获得container.xml中注册的组件实例，这种方法每次调用获得的是同一个实例，相当于单例方式获得。

public Object getComponentNewInstance(String name);

每次从容器中获得container.xml中注册的组件的一个新实例，这种方法每次调用获得的是新的实例，该方法不适合一些单例资源的获得。

例如如果向在POJOService中访问容器的缓存机制，因为缓存整个容器只能有一处，因此必须以lookup方式获得，获得ModelManager的实例如下：

ModelManager modelManager = containerWrapper. lookup (“modelManager”);

其中“modelManager”字符串名称是从Jdon框架的jdonFramework.jar包中META-INF的container.xml中查询获知的。

AOP包

Jdon AOP的设计目前功能比较简单，不包括标准AOP中的Mixin和Introduction等功能；AOP包下有几个子包：Interceptor、joinpoint和reflection，分别涉及拦截器、；拦截器切点和反射机制等功能。

bussinessproxy包

Jdon框架从架构角度来说，它是一种业务代理，前台表现层通过业务代理层访问业务服务层，使用AOP实现业务代理是一种新的趋势，因此本包功能是和AOP包功能交互融合的。

bussinessproxy包中的config子包是获取jdonframework.xml中的两种服务EJB或POJO配置，然后生成meta子包中TargetMetaDef定义。

target子包封装了关于这两种服务由元定义实现对象创建的工厂功能，服务对象创建透过访问模式使用了HttpSession作为EJB实例缓存，这个功能主要是为了EJB中有态会话Bean实现，这样，客户端通过getService获得一个有态会话Bean时，无需自行考虑保存这个Bean引用到HttpSession中这一使用细节了。无态会话bean从实战角度发现也可以缓存，提高了性能。

Jdon框架既然是一种业务代理，那么应该服务于各种前台表现层，Jdon框架业务代理还适合客户端为Java客户端情况下的业务服务访问。这部分功能主要是com.jdon.bussinessproxy.remote子包实现的。使用方式参考：http://www.jdon.com/product/ejbinvoker.htm

TargetMetaDef

TargetMetaDef是目标服务的元定义，TargetMetaDef主要实现有两种：EJBTargetMetaDef和POJOTargetMetaDef，分别是EJB服务和POJO服务实现。

所谓目标服务元定义也就是程序员在jdonframework.xml中定义的services。

Jdon框架提供目标服务两种形式：目标服务实例创建和目标服务本身。

ServiceFactory

目标服务创建工厂ServiceFactory可以根据目标服务元定义创建一个目标服务实例，这也是WebAppUtul.getService获得目标服务的原理实现，

com.jdon.controller.service.DefaultServiceFactory是ServiceFactory缺省实现，在DefaultServiceFactory中，主要是通过动态代理获得一个服务实例，使用了DefaultServiceFactory来实现动态代理对象的缓存。不必每次使用Proxy.newinstance第一次执行后，将其结果保存在HttpSession中。

Service

目标服务Service则是通过方法Relection运行目标服务，只要告知Service目标服务的类、类的方法、方法参数类型和方法参数值这些定义，除了方法参数值，其余都是字符串定义，这是Java的另外一种调用方式。

security包

Security包主要应用于JdonSD（一个组件库）产品的基于容器的安全权限认证。

strutsutil包

本包封装了Jdon框架基于Struts的表现层实现，Jdon框架的CRUD功能和批量分页查询以及树形显示功能都是在该包中实现，还有上传图片等功能（待测试）。

controller包

controller包是Jdon框架的整体结构包，主要面向框架使用客户端，其中WebAppUtil是经常被调用的类。

cache子包是框架的缓存机制，这个缓存机制主要面向数据类设计，例如Model类，功能类是通过container实现管理，功能类使用访问者模式实现结合HttpSession实现有状态。

Jdon框架缺省缓存是使用了开源OfBiz的一个缓存，如果你希望使用更好的缓存产品。可以通过继承Cache或LRUCache，然后在container.xml中替代如下配置即可：

</component>

cache子包提供的缓存不但为Model服务，还为批量查询的PageIterator创建服务，可参见PageIteratorSolver类；另外也为上传图片缓存服务，以后可拓展为更多数据性缓存服务。

Config子包主要是为读取pojoService和ejbService配置实现XML读取功能。

Events子包包含的是装载数据Model载体在各层之间穿梭，类似信使，通常表现层会将Model封装到EventModel中，传给服务层的服务，服务处理完毕，如果出错将出错信息封装在EventModel对象中，这样表现层可从EventModel中查知后台处理是否出错，并返回出错信息。

EventModel的setErrors方法是用于服务层封装处理出错信息的方法，可直接将”id.notfound”这样约定出错信息赋值进去，前台如struts可根据id.notfound到Application.properties中查找本地化信息提示。

Model子包是封装了框架重要的数据类Model，Model既是域模型中的Model，也是一种DTO，它是在各层之间传送数据的载体，因此Model可以允许嵌套Model，DynamicModel也许更加适合临时组装一个传送对象。

Model是框架的CRUD功能重要角色；PageIterator是框架批量查询的重要角色。

Pool子包封装了Apache Pool功能，主要用于Pool拦截器，如果你的POJO服务需要池化提升性能，只要让你的POJO服务类继承该包下的Poolable即可。

Service子包封装框架两大有关服务的重要功能：创建一个服务ServiceFactory.create；或直接运行一个服务Service.execute。

model包

model包主要是围绕Model的CRUD功能实现展开，这部分是中间层，尽量做到和表现层strutsutil包实现解耦，这样如果有新的表现层如JSF可直接和本包发生作用，实现JSF下的CRUD功能。

ModelManager是面向表现层操作Model的主要客户端类，ModelForm和ModelHandler都是可能需要客户端继承实现的重要类。

Config子包主要是从jdonfamework.xml中获得models相关配置，将这些加载到ModelMapping对象中。

Handler子包是延续config子包，model配置中Modelhandler部分配置被加载到HandlerMetaDef对象中，然后预先实现class.forName运行，HandlerObjectFactory是创建ModelHandler实例工厂，一次性生产20个，如果不够用，还可以再生产20个，因为ModelHandler为struts的action直接调用，而action是多线程，所以使用这种池形式可提高性能，这里使用了自制的池功能，原理简单，池性能好，简单性能就好是Jdon框架设计一个原则。