框架的可移植代码?

在可能的情况下,尝试将业务逻辑与“交互层”分开。基本上,这个交互层包装对底层框架的调用,所以您的应用程序将与这个层对话,然后这个层用于与框架对话。

通过这样做,您可以通过只根据不同的框架重写交互层来挽救一些东西。

或者,您可以建议您不必仅仅因为有一个新的版本而升级框架,或者因为框架不再被维护。通常,更新的决定是由技术人员做出的,并且没有真正的业务案例来支持它;请看COBOL和VB6应用程序的数量,它们仍然在运行,几乎没有维护。

尽可能多地抽象可以使您远离框架问题。

我给你举个例子。我最近开始和CodeIgniter合作。我很欣赏这个框架所做的一些工作,但我不喜欢它的其他方面。我不喜欢的一件特别的事情是,对于您编写的每个应用程序,您几乎都必须使用一个单独的CI副本。如果CI推出了新版本,我必须返回并升级多个应用程序。

因此,我在自己的CI安装中创建了一个名为“base”的单独目录,并设置了一个PHP自动加载程序,以便能够从中加载类。我有“base_controller”、“base_service”、“base_model”等,我在所有的CI安装中都使用它。这些类扩展了常规的CI类,而我的应用程序又扩展了这些基类。例如,在应用程序1中,而不是编写扩展CodeIgniter的控制器类 Controller 班上,我把我的 Base_controller 从而扩展了CI 控制器 .

这让我在CI和我的应用程序之间有了一个层次的分离。如果CI发生变化,我应该能够通过只升级我的“基础”层来管理它。在这一层中,我还可以有很多基本功能,并且只写一次,而不是每次都扩展一个新的CI安装。

抽象需要仔细的设计,因为您不想过分追求它。但它绝对是将代码与框架代码分离的有用工具。

• 研究你的选择。
• 根据以下条件选择一对:
  • 相似性(模板代码、架构、javascript库)
  • 多样性(当然不是由同一个人维护的)
  • 简单性(框架越简单,移植就越容易)
• 研究您的两个备选方案并准备好迁移路径(即,我们必须重写这个和那个,并在这里调整数据库层)

也就是说,如果php是您的语言,我真的非常怀疑Zend框架是否会消失:—)

选择一个开源框架?然后,如果原始维护人员离开,您仍然可以维护代码。

一些防御措施可能是:

-适配器模式

-如果它是一个开放源码框架,您可以自己开发它,或者分叉它。不再开发的框架并不意味着代码会被破坏。

-根据框架的不同,模型与框架分离。Zend框架没有指定您使用活动记录。所以您的模型应该与数据库层分离。因为模型是应用程序中最困难的部分,所以如果模型与框架(控制器、视图和数据库层)分离,那么将其修改为备选框架就没有那么困难了。