D 的个人博客

但行好事莫问前程

  menu
417 文章
3446695 浏览
10 当前访客
ღゝ◡╹)ノ❤️

关于StoneAgeDict的当前架构小结

从上次迭代结束(14号)到今天,基本完成了系统核心框架设计。

按照我们的计划,现在是迭代1阶段,貌似在进度上还是计划得比较好。不过,这3天一直忙着一面学习OSGi,一面重构核心框架,有的任务可能耽搁了点:-)

但是,我们的应用框架现在更合理了,呵呵。说一下目前的设计:

基于OSGi的面向服务组件模型

所有工程编译打包后都作为了一个组件,提供一定的服务。目前,我们有

DesktopApp组件:StoneAgeDict桌面版本GUI

DictsManager:词库管理器,管理用户下载的、自定义的词库

StarDictQueryEngine:StarDict(星际译王)词库的查询引擎

在没有基于OSGi框架以前,迭代0完成的时候代码量有5000多行。基于OSGi后(由于框架方面不用操心,删除了N多的工厂类,还有减少了很多 抽象类),代码量为3000多行。可以看出,重用OSGi框架不仅使我们的系统有了SOA的味道,大家都可以以相同的服务视角去看系统,易理解,而且在开 发的复杂度上大大降低了。

举个例子,以前拿到需求,都是只停留在了OO的层次上做的设计。团队开发的时候还是以类/包,或者子系统的方式分工,感觉不是很高效。特别是设计的 时候,interface类/abstract类,Factory类作为了整个系统各个部件之间解耦的关键,需要投入相当多的时间去设计和实现。即便这 样,系统以后应变的能力还是不能太好,特别是随着系统变得越来越巨大的时候,维护的代价可能是成指数倍的。而基于OSGi框架,Component- Oriented,甚至是Service-Oriented的高度去设计的话可以把整个应用的架构做得更好。对于每个素服粗件,我们都需要清晰地定义出它 Import和Export的服务,而且这是纯服务,内部实现完全被隐藏了!加上OSGi提供对于每个服务组件的版本描述,可以很好地解决组件更新的问 题。这样,我们可以实现极低耦合的系统,而且系统功能还可以无限扩展!


关于Spring与OSGi的整合

以前用Spring这个IoC容器,感觉那个神奇啊,如今用OSGi这个组件服务框架,感觉那个实用啊!

呵呵。。。。

话说回来了,如果要做Java的Web应用,Spring应该是首选框架。理论上来说,OSGi可以整合Spring进去,不过这样做貌似比较困难。。。。

还是用Spring整合OSGi,网上教程比较多,有把握。只要Spring可以调用OSGi里的各种Bundles,目的就达到了!

 

Flex和Spring的整合

StoneAgeDict的Web界面上,目前暂定使用Adobe Flex。接触一下RIA的技术,还是比较好的。

关于Spring和Flex整合,这个问题应该不是很复杂。这两个都是当前业界用得比较多的,所以技术上可以完成。

 

通过前面的介绍,我们的系统整体架构上用到的技术/框架基本就是

Web方面:Flex + Spring + OSGi

桌面方面:Swing+ OSGi

所有基础服务全部做到OSGi里,然后。。。。三个框架整合一把,不知道要有多少“胶水配置代码”,呵呵。