是否可以将应用程序宽松地耦合到其框架？

假设我正在开发一个Web应用程序。我的首选是将PHP与无脂肪框架（F3）和MVC模式结合使用。明年，我可能会决定我要切换到Zend Framework，或者甚至是ASP.NET MVC。尝试以松散耦合到其框架的方式设计应用程序是否有意义，或者该框架是否过于完整以至于无法实现这一目标？

我问的唯一原因是因为它最近与一位同行进行了交谈，这位同行批评我的派是将应用程序与F3松散耦合的想法。

松散地将您的应用程序耦合到其框架实际上意味着您将要编写一个代理框架。编写该代理框架需要大量工作，如果您切换到新框架，则必须做很多工作才能使代理框架支持新框架。当然，不同的框架使用不同的习惯用法和模式，这会使代理框架非常复杂（如果您尝试使其适合所有事物）或非常有限（如果您使用最低的公分母）。无论哪种方式，您都将不得不使用该代理框架。

能够一时兴起地更改框架是否值得所有这些麻烦？就像我说的那样，您将一时无法更改它，因为您将不得不调整代理框架，这可能比直接调整应用程序代码还要费劲。

没办法

您可以采用可跨框架移植的方式进行设计。MVC是MVC，无论使用哪种语言或平台，其原理都大致相同。

但是，实际的代码将非常依赖于框架或语言。使自己抽象的唯一方法是基于中间框架进行编码。然后，您可以进行中间实现更改（从F3到.NET？），而无需更改应用程序。要做很多工作，假设没有泄漏的抽象，只是解决问题而没有解决问题：您现在已与中间框架联系在一起。

更积极的一点是：考虑在独立于实现的平台上表达一些测试（BDD风格）。这些可能会幸免于重大改写。

我曾经见过罗伯特·C·马丁（Robert C. Martin）演讲，他说的话是“您做出的第一个决定是以后最难改变的决定”。

因此，我的建议是，如果您不确定要使用的内容，请尝试延迟此决定。确定您现在可以定义的部分，这些部分将很容易与最终使用的框架无关。

框架锁定可能是一个严重的问题，但有助于将问题视为可移植性之一。可移植性不是绝对的属性，而是相对于您的起点以及您可能想去的地方。以此类推，仅当您已经将软件移植到其他环境时，该软件才是可移植的。

框架内应用程序的大多数开发工作往往是粘合代码，这些代码将框架的各个组件绑定在一起。配置文件可能会在某些系统中抽象出一定数量的粘合剂，但是许多细节必须用代码来完成。

另一方面，可以从应用程序中抽象业务规则和流程。抽象的困难之处在于规则是由框架直接实现的。安全性，可访问性和流程排序通常由您的框架来强制执行，并且可能最难看到。

如果您可以将应用程序的粘合部分与业务规则以及业务流程和业务数据部分分开，那么您将能够使解决方案的某些部分具有可移植性。