Jdon的设计架构资料能不能共享一下?

我觉得Jdon的思想非常好,比如:DCI,DDD,CQRS,Event Source等。但思想比较不能脱离现实,必须能够服务于现实中的实际需求。因此我很想了解Jdon是如何实现这些先进思想的,JF作为一个开源项目,可以直接看源代码分析,但是耗时耗力,所以特别想看下Jdon的设计架构文档,结合源代码分析,这样将是对JF最深入的了解。不知道大侠能否提供一份源代码级别的设计架构文档!3Q!
[该贴被admin于2013-01-25 08:29修改过]

关键是理解这些思想,只是使用Jdon框架可方便实践出来,Jdon框架如同是画笔 颜料,充其量颜料种类丰富些,至于和印象派或现代派艺术风格等关系不大,Jdon框架是一个包裹了Disruptor和AOP+IOC的框架,具体运行方式可设断点跟踪一下。比较简单。

融合这些思想的是Jdon分析法,而不是Jdon框架。

[该贴被banq于2013-01-25 08:49修改过]

感谢回复!今天看了下JF的启动流程,了解一些接口和类,做了个笔记,不知道理解是否正确?
ServiceFacade:Service门面,Jdon框架通过ServiceFacade来获取serviceFactory。ServiceFacade内部使用ContainerFinder接口(见下)来获取容器,目前使用ContainerFinderImp
ServiceFactory(interface):服务工厂,客户端统一使用ServiceFactory来获取服务。
AppContextWrapper(interface):上下文包装器,定义统一Jdon的上下文接口。将各种不同的上下问,包装为AppContextWrapper后,方便Jdon框架统一处理。该接口有两个子类ServletContextWrapper用来包装ServletContext,Application用来包装HashMap实现非Web环境上下文
ContainerWrapper(interface):容器包装器,定义了Jdon IoC容器的接口,这样就可以将各种容器适配到该接口上,目前Jdon框架使用的是PicoContainerWrapper。如果想使用Spring容器,则将Spring容器适配为ContainerWrapper接口,然后再编写一个实现了ContainerFinder接口的类ContainerFinderForSpring,专门用来初始化Spring容器。最后将ContainerFinderForSpring注入到ServiceFacade中即可实现底层容器的置换。但是由于ServiceFacade不能注入ContainerFinder(上面提到过了)所以需要修改一下源代码。
PicoContainerWrapper:是JdonPicoContainer的包装类实现了ContainerWrapper接口。将底层JdonPicoContainer容器对象适配到Jdon框架的ContainerWrapper接口上。作为一个适配对象自身并不实现自有逻辑功能,基本上是将逻辑委托到真正的容器对象JdonPicoContainer上。自己主要实现一些辅助功能。PicoContainerWrapper关键业务逻辑在其构造函数中,直接实例化JdonPicoContainer对象,并将JdonComponentAdapterFactory对象作为JdonPicoContainer容器的ComponentAdapterFactory,这样JdonPicoContainer对象将使用JdonComponentAdapterFactory来创建JdonConstructorInjectionComponentAdapter对象。
JdonPicoContainer:JF的底层容器对象。实现了picocontainer框架中MutablePicoContainer接口和ComponentMonitorStrategy接口。
JdonPicoContainer的注册方式
a、Instance注册
直接示例化InstanceComponentAdapter对象,调用统一注册方法registerComponent()注册
b、Implements注册
最终通过调用工厂方法ComponentAdapterFactory.createComponentAdapter()生成ComponentAdapter实例后,调用统一注册方法registerComponent()注册
JdonPicoContainer的获取实例过程
a、获取ComponentAdapter对象
如果以Object为参数获取componentAdapter对象,JdonPicoContainer将直接从componentKeyToAdapterCache缓存中去取componentAdapter;
如果以Class为参数获取componentAdapter对象,JdonPicoContainer将先尝试从componentKeyToAdapterCache缓存中去取componentAdapter,如果取不到将调用getComponentAdaptersOfType(Class)方法,获取当前环境中所有与该Class匹配的componentAdapter,如果只有一个则返回该componentAdapter,如果没有则到父容器中找,否则返回null,如果多于一个,则抛出异常
//==remark==
//因此使用getComponentAdapter(Object)方法更加安全,一般Object为String类型,即该实例对象的别名。但通过别名获取实例,有硬编码的嫌疑,不太灵活
//而getComponentAdapterOfType(Class)方法是在不太清楚对象的别名的情况下才使用,效率比较低,而且会跑出异常。但是该方法不通过别名获取实例,防止了硬编码的方式,代码更灵活
b、根据componentAdapter创建实例
都是先根据参数先获取到componentAdapter后,统一调用getInstance(ComponentAdapter)方法来获取实例。而真正的获取实例的业务方法确实在componentAdapter内部实现,因为Jdon使用JdonComponentAdapterFactory来创建componentAdapter对象的,所以实际上使用的JdonConstructorInjectionComponentAdapter。所以JdonConstructorInjectionComponentAdapter.getComponentInstance()方法才是获取实例的核心方法。
ContainerFinder(interface):Jdon框架使用该接口来查找ContainerWrapper,该接口实现类需要实现初始化各种容器的方法,也可以说是创建ContainerWrapper工厂方法,目前Jdon框架中该接口只有一个实现类ContainerFinderImp,该类使用ContainerSetupScript(见下)来构建ContainerWrapper。
ContainerRegistryBuilder(interface):容器构建接口,定义了构建一个容器所必须实现的方法。该接口的默认实现是DefaultContainerBuilder实现了注册组件、注册apsect组件,注册用户service,启动状态检查,启动/停止应用等方法,AnnotationContainerBuilder继承了DefaultContainerBuilder,额外实现通过类注解来实现组件、apsect组件、用户service的注册。
ContainerSetupScript:该类使用ContainerRegistryBuilder接口,将容器的构建使用过程进一步封装。主要封装了四个方法,prepare:准备,initialized:初始化,startup:启动,destroyed:销毁。ContainerFinderImp会先调用prepare(),再调用startup()方法来完成ContainerWrapper构建。
prepare:调用ContainerDirector.prepareAppRoot(),为后续初始化组件做好准备
initialized:该方法中读取xml配置文件信息生成容器组件集合对象ContainerComponents,还扫描类路径下所有类,将使用Jdon注解的类的信息放入到内存中,以供后续在startup方法中使用这些数据。
startup:调用ContainerDirector.startup(),Jdon启动的主要逻辑集中在该方法中。
destroyed:调用ContainerDirector.shutdown()
ComponentAdvsior:使用GClib来动态创建代理,具体扩展逻辑在CGLIBMethodInterceptorImp中。如何获取实例拦截方法集、如何获取实例拦截器,如何创建代理在此类中实现
CGLIBMethodInterceptorImp:实现了GClib包的MethodInterceptor接口。成为一个GClib的方法拦截器,JF AOP的核心逻辑便在此对象intercept方法中实现
[该贴被winner8009于2013-01-26 15:27修改过]

2013-01-26 15:21 "@winner8009"的内容
今天看了下JF的启动流程 ...

很厉害,我都没有你理解得如此精细啊。可以作为其他人有兴趣研究Jdonframework的参考文档。