框架的可移植代码？

Question

我们已经决定使用“在这里插入框架”

当它们出现时，我们很可能会更新到框架的下一个主要版本--然而，上层管理人员担心的是，如果框架滚动结束并死亡，代码变得无人维护怎么办？这种情况发生的可能性非常低，但我仍然必须捍卫这一立场。

我故意没有提到将所有答案保持在通用级别的框架，因为我知道这里的框架讨论大多是观点。

所以，现在我要面对的问题是：

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

Answer 1

在可能的情况下，尝试将业务逻辑从“交互层”中分离出来。基本上，这个交互层封装了对底层框架的调用，因此您的应用程序与该层进行通信，然后该层用于与框架进行通信。

通过这样做，您只需针对不同的框架重写交互层，就可以挽救一些东西。

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

Answer 2

尽可能多地抽象可以将您与框架问题隔离开来。

我给你举个例子。最近我开始经常使用Codeigniter。我很欣赏这个框架所做的一些事情，但我不喜欢它的其他方面。我特别不喜欢的一件事是，您几乎必须为您编写的每个应用程序使用单独的CI副本。如果CI发布了较新的版本，我必须回去升级多个应用程序。

因此，我在CI安装中创建了一个名为"base“的单独目录，并设置了一个PHP自动加载器，以便能够从其中加载类。我有类似"Base_controller"，"Base_service"，"Base_model“等的东西，我在我所有的CI安装中都使用这些东西。这些类扩展了普通的CI类，反过来，我的应用程序扩展了这些基类。例如，在应用程序1中，我没有编写一个扩展Codeigniter的Controller类的控制器类，而是扩展了我的Base_controller，这反过来又扩展了CI Controller。

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

抽象需要仔细的设计，因为你不想做得太过火。但它绝对是一个有用的工具，可以将你的代码与框架的代码分开。

Answer 3

基于以下几点来研究你的alternatives.

• Choose：
• • 相似度(模板代码，架构，javascript libraries)
  • Diversity (不是由相同的人维护的，course)
  • Simplicity的)(你的框架越简单，移植你的javascript就越容易

​

• 研究您的两个备选方案，并准备好迁移路径(即，我们必须在此处重写这个或那个并调整数据库层)

也就是说，如果PHP是你的语言，我真的，真的怀疑Zend框架会消亡:-)