便携式框架代码？

Question

我们决定使用“Insert Framework Here”

我们很可能会在框架出现时更新到框架的下一个主要版本 - 但高层管理人员担心的是，“如果”框架滚动并且死亡，代码变得无法维护？发生这种情况的可能性非常低，但我仍然需要捍卫这一立场。

我故意没有提到将所有答案保留在通用级别的框架，因为我知道这里的框架讨论主要是所有意见。

所以，现在谈谈我面临的问题：

我们可以做些什么来保持我们的代码可移植到框架？

Answer 1

尽可能尝试将您的业务逻辑与“交互层”分开。基本上，这个交互层包含对底层框架的调用，因此您的应用程序会与该层对话，然后用于与框架进行通信。

通过这样做，您可以通过仅针对不同的框架重写交互层来挽救某些东西。

或者，您可以建议您不必升级框架只是因为有新版本，或者因为不再维护框架。通常，更新的决定是由技术人员做出的，没有真正的商业案例来支持它;查看仍在运行但几乎没有维护的COBOL和VB6应用程序的数量。

Answer 2

尽可能抽象可以使您免受框架问题的影响。

我会举个例子。我最近开始与Codeigniter合作。我很欣赏框架所做的一些事情，但我并不喜欢它的其他方面。我不喜欢的一个特别之处是你几乎必须为你编写的每个应用程序使用单独的CI副本。如果CI推出了更新的版本，我必须返回并升级多个应用程序。

因此，我在CI安装中创建了一个名为“base”的独立目录，并设置了一个PHP自动加载器，以便能够从中加载类。我有“Base_controller”，“Base_service”，“Base_model”等等，我在所有CI安装中使用它。这些类扩展了普通的CI类，反过来我的应用程序扩展了这些基类。例如，在应用程序编号中，不是编写扩展Codeigniter的Controller类的Controller类，而是扩展我的Base_controller，后者又扩展了CI Controller。

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

抽象需要精心设计，因为你不想过度使用它。但它绝对是将代码与框架代码分开的有用工具。

Answer 3

• 研究你的选择。
• 根据以下内容选择一对：
  • 相似性（模板代码，架构，javascript库）
  • 多样性（当然不是由同一个人维护）
  • 简单（框架越简单，移植的麻烦越少）
• 研究你的两个选择并准备好迁移路径（即，我们必须重写这个，并在此调整数据库层）

那就是说，如果PHP是你的语言我真的非常怀疑Zend Framework会死： - ）

Answer 4

选择一个开源框架？然后，如果原始维护者离开，您仍然可以维护代码。

Answer 5

一些防御措施可能是：

-Adapter pattern

- 如果它是一个开源框架，你可以自己开发，或者分叉。不再开发的框架并不意味着代码消失了。

- 根据框架，模型与框架分离。例如，Zend Framework没有指定您使用活动记录。因此，您的模型应该与数据库层分离。由于模型是应用程序中最困难的部分，因此如果模型与框架（控制器，视图和数据库层）分离，将其修改为替代框架并不困难。