现在的框架多如牛毛,每种框架都会告诉你如何使用它。遗憾的是,仅仅从这个角度来看如何使用框架,一般都用不好。为什么呢?想想下面这个问题。
你想过框架升级/替换带来的问题吗?
举个例子,你已经使用了jBPM3,当jBPM4、5来的时候,你将如何把它们引入到自己的系统,并替换原有的框架,你将付出怎样的代价来做到这一点?
如果你从来没有想过上面的问题,你的系统往往和框架绑定过紧,在你的业务逻辑代码中,混杂着某个框架或某个框架版本的API。当新的框架面世时,你只能在一边垂涎三尺,或者花费巨大的代价来做出改变。原因很简单,因为你没有从架构的层面考虑可移植性问题。可移植性,很简单的一个词,但你真正理解它了吗?
基于可移植性,你就会正确地使用框架。下面画了一张图。
图中,左边的Framework是可替换的,右边的Business Logic是业务逻辑,其中只包含模型,基于模型的计算,以及开放出来的API,理想的情况下,只包含POJO,中间的Bridge Layer是针对Framework和Business Logic的桥梁。开发人员致力于Business Logic和Bridge Layer,其中,Business Logic是独立演化的,不受外界的影响,Bridge Layer会随着Business Logic和Framework的变化而变化。Bridge Layer中不包含任何业务逻辑的实现,它只是在Framework和Business Logic之间建立联系,例如,流程中的一个Action,这个Action只是根据流程的业务含义,转调Business Logic中的API。
需要注意的是,Framework是驱动方,而不是Business Logic。Framework根据Bridge发出的信号,驱动Bridge的工作,Bridge的工作内容,就是调用Business Logic中的API,从而完成业务逻辑。如果用Business Logic来驱动Framework,就是绑定过紧的开始。
基于上述的理论和概念,才能真正用好框架,尤其是解决可移植性问题,这一点很重要。