现在的框架多如牛毛，每种框架都会告诉你如何使用它。遗憾的是，仅仅从这个角度来看如何使用框架，一般都用不好。为什么呢？想想下面这个问题。

你想过框架升级/替换带来的问题吗？

举个例子，你已经使用了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，就是绑定过紧的开始。

基于上述的理论和概念，才能真正用好框架，尤其是解决可移植性问题，这一点很重要。