请教模块化可移植开发问题

请教一个项目开发问题,我想做一个Web项目,要求做成模块化,插件式
比如一个用户角色管理模块,软件上传下载列表模块,文章管理模块,这是比较通用的模块,我想做一次能够方便的移植.做一个主系统,单个模块以插件的形式安装到系统中,需要时可以通过少许配置直接安装到新的系统中去,而不需要重新开发.


目前我们公司做的一个系统里面的东西差不多都是很死的,他们做新系统的时候都是复制代码,有一个底层框架,包括用户和一些自定义标签,cache等,页面对象.目前公司的框架已经开发了好几个项目了,但是最近发现框架中session共享有很大打bug,目前也没有考虑修复,因为耦合太严重了,几乎所有的页面都使用到了自定义的page和view对象,这些对象在session里面没有很好控制共享冲突.而且每个系统都是复制的底层代码,很多模块也都复制的,造成很多乱七八糟的问题.

我想如果是模块插件式的开发就会减小系统耦合(并不是要修复公司系统缺陷),这样也减少开发次数,如果有缺陷修复工作量也相对较小.不知道有没有关于模块化开发的案例或者这方面的设计思想?

前几天看了些osgi的教程,osgi发展这么多年了,桌面应用蛮成熟了,但是web应用还是支持的很不好,至少很多框架的集成都有或多或少的问题.

请高手帮忙解答下一些关于分块的插件式开发要考虑些什么东西?移植性如何?还有就是怎么样细化模块比较好?

这个问题,我觉得还是得用OSGi。OSGi是目前解决这一问题的最理想方案。至于你说的框架集成等问题,我相信随着OSGi的发展和普及,这方面会越来越好。Sun的glassfish v3就是用OSGi实现的,你还担心日后业界对OSGi的支持不够吗?。目前spring就有Dynamic Module来支持OSGi,更进一步推出了OSGi application platform——spring dm server,并且不仅仅用OSGi实现了application server的功能,还把OSGi框架本身暴露给部署在dm server上的App,这在目前众多基于OSGi的app server中,是绝无仅有的。
[该贴被dearshor于2008-12-28 11:53修改过]

个人感觉osgi发展至今快10年了,除了桌面应用以外很少有web方面的应用,而且除了spring osgi以外,其他框夹如hibernate,webwork都支持不好,我看了些osgi的教程,osgi网站,似乎都没有什么更新了,最近的技术在osgi上的使用集成存在很大问题.看到有人将hibernate改装后集成到osgi,但是这种集成或多或少降低了hibernate的性能,如hibernate的cache,事务等,如果不能很好的发挥hibernate等框架的优势,那集成了框架和没有框架没什么区别.
osgi在eclipse上很成功,在web上却始终存在很多集成的问题.而且现在很多集成框架的方案是用equinox扩展,这样也就和equinox帮定了,不能很好移植到felix等其他osgi框架.
个人感觉osgi的动态扩展是一大障碍,通常情况下web程序静态扩展就足够了,从软件开发方面来说,我最看重的是重用性和系统的集成性能,是否能够动态的安装停止所谓的bundle并不重要.

个人认为不是通用框架产品能够解决你的问题,只能依靠你们自己的业务设计,比如使用Evans DDD方法,进行OO建模和设计。

这和OSGI没有关系,不要期待神奇框架会从地面上升起,自己的软件产品质量关键依靠自己的设计水平,这是雕塑大师和雕塑工的区别。

同意banq老师的观点,今天在theserverside上看了一个关于耦合和服务文章,指出了类似观点,框架只能解掉结构上的耦合,但是逻辑上的耦合别指望框架,只能靠建模。比如一个在线考试系统,各个形式的考试分别是不同的模块,这个系统希望以后增添新考核方式的时候能像插件一样插入,也希望不再使用的考试模式从系统中方便清除,通过良好的架构设计当然可以做到模式模块的想删就删,想加就加。但是忘了每次更改都是业务上的更改,业务又有无限制关联性,你应该考虑到新增的考核方式是不是需要已有的评分模块进行更改等等问题,这个问题只能通过基于业务建模解决,即所有新增的考试模块必须符合某种规律,对评分模块以某种通用形式调用,这个就要看业务建模的好坏了。

banq前辈所说的“依靠你们自己的业务设计,比如使用Evans DDD方法,进行OO建模和设计”我完全同意,我并不是说用了某某OSGi框架就能指望这个框架帮你搞定一切,你什么设计工作都不用干了。

OSGi是Java EE领域里一种全新的(区别于“传统)程序设计模型,架构方式,部署方式。虽然诞生了很久,但由于原本是用于嵌入式领域的,直到eclipse发现了它,把它作为eclipse IDE的核心架构,并取得了极大的成功以后,人们才渐渐发现其价值,并开始把它引入Java EE领域,所以目前确实存在楼主所说的种种问题(“很多框架的集成都有或多或少的问题”“在web上却始终存在很多集成的问题.而且现在很多集成框架的方案是用equinox扩展,这样也就和equinox帮定了,不能很好移植到felix等其他osgi框架”)。

但随着各大Java EE application server厂商对纷纷推出基于OSGi的app server(尤其是spring source的dm server不仅仅用OSGi实现了application server的功能,还把OSGi框架本身暴露给部署在dm server上的App,这对部署基于osgi的应用带来了极大的便利),我有理由相信开发、部署、移植OSGi app会越来越方便,基于OSGi的Java EE 解决方案会越来越成熟。

See Also:
企业中的OSGi

On 2008年12月28日 15:50 , fugary wrote:
>个人感觉osgi的动态扩展是一大障碍,通常情况下web程序静态扩展就足够了...是否能够动态的安装停止所谓的bundle并不重要.

能否详解一下你为什么“感觉osgi的动态扩展是一大障碍”?
"是否能够动态的安装停止所谓的bundle"我认为无论是开发环境还是生产环境,都有着重大意义。

1.开发环境。做Java EE的都遇到过这样的问题吧:修改了Java代码后,需要重新打包,然后整个包重新deploy,才能让change生效,这样使得code-deploy-debug这样一个cycle变得很麻烦很缓慢;即便使用了exploded package的方式来部署,依然需要整个package redeploy,而无法实现“增量部署”;如果被修改的那个package还依赖于其他的package或被其他package依赖的话,更是需要把所有相关联的package都redeploy一遍...这是难以忍受的!
而采用osgi架构的话,则有可能真正彻底解决此问题。我修改了一个bundle之后,直接更新这个bundle即可,其他依赖它的bundle与它依赖的bundle都可以自动发现这些更新,然后可以更新它们自己。这些bundle还可以(使用Evans DDD方法,进行OO建模)精心设计和合理划分,使得更新、添加、删除其中一个bundle的开销降到最小。 Cool, isn't it?
这点在生产环境中也有大用处!!

2.生产环境。能完美解决运行时系统升级、扩展的问题,理由上面已经说了。
[该贴被dearshor于2008-12-29 19:18修改过]