将 CGI 迁移到框架的最佳方法是什么？答案

【问题标题】：What's the best approach to migrate a CGI to a Framework?将 CGI 迁移到框架的最佳方法是什么？
【发布时间】：2010-09-13 23:10:07
【问题描述】：

我有一个在 perl CGI 中运行的大型 Web 应用程序。它运行正常，写得很好，但是就像过去所做的那样，所有的 html 都是在 CGI 调用中硬编码定义的，所以你可以想象，它很难维护、改进等等。所以现在我想开始添加一些模板并与框架（催化剂或 CGI::application）集成。我的问题是：这里有人有这样的经历吗？有什么需要注意的吗？我知道使用这两个框架我都可以运行本机 CGI 脚本，所以这很好，因为我可以同时运行这两个（CGI 本机广告“框架化”代码）而不会造成任何创伤。有什么建议吗？

【问题讨论】：

标签： perl model-view-controller cgi catalyst

【解决方案1】：

首先编写测试（例如使用Test::WWW::Mechanize）。然后，当您更改某些内容时，您始终知道是否有问题，以及发生了什么问题。

然后将 HTML 提取到模板中，并将常用的 subs 提取到模块中。之后切换到框架就是小菜一碟了。

一般来说，一步一步来，这样您的应用程序始终可以正常工作。

【讨论】：

【解决方案2】：

从 CGI 脚本中的处理逻辑中提取 HTML。识别影响 HTML 输出的所有代码，因为它们是成为模板变量的候选者。将其分离到一个 HTML 文件中，并用模板变量标记已识别的部分。最终，您将能够重构页面，以便在代码开始时完成所有处理，并在所有处理结束时调用 HTML 模板。

【讨论】：

【解决方案3】：

在这种情况下，基本上从头开始重写，旧代码对于 A) 测试和 B) 设计细节很有用。理想情况下，您应该针对您想要复制的所有基本功能进行一组测试，或者至少对解析最终结果页面的测试进行测试，以便您可以看到新代码为相同的输入返回相同的信息。

代码中的设计细节可能毫无用处，这取决于框架自动处理的程度。如果您有一组良好的测试，并且简单的转换效果很好，那么您就完成了。如果新的行为与旧的不匹配，您可能需要更深入地挖掘“为什么？”这可能看起来很奇怪，乍一看没有意义。

首先要记住要做的一件事是，找出是否有人在您使用的框架中制作了类似的东西。您可以为自己节省大量时间和金钱。

【讨论】：

从头开始重写对于超过 5k 行的系统是不可行的。但无论如何，感谢您的投入！

【解决方案4】：

这是我使用 Python 而不是 Perl 的方法，但这不重要：

将 HTML 和代码分离到不同的文件中。为此，我使用了模板引擎。
从代码创建了函数，该代码用一组参数呈现了一个模板。
以合理的方式组织函数（我将其称为views，受Django 启发）。（管理员视图、用户视图等）视图都遵循相同的调用约定！
重构了数据库和请求内容，以便视图将仅包含视图特定代码（阅读：处理 GET、POST 请求等，但没有低级！）。为此严重依赖现有库。

我现在在这里。 :-) 下一个明显的步骤当然是：

编写一个 dispatcher，将 URLs 映射到您的视图。当然，这也将导致更好的 URL 和更好的 404 和错误处理。

【讨论】：

【解决方案5】：

框架做出的假设之一是 url 映射到代码。例如，在一个框架中，您会经常看到以下内容：

http://app.com/docs/list
http://app.com/docs/view/123

通常虽然旧的 CGI 脚本不能这样工作，但您更有可能遇到类似的情况：

http://app.com/docs.cgi?action=view&id=123

要利用该框架，您可能需要更改所有网址。您能否做到这一点，以及如何保持旧链接正常工作，很可能构成您决定的很大一部分。

框架还提供对某种 ORM（对象关系映射器）的支持，它抽象了数据库调用并让您只处理对象。对于Catalyst，这通常是DBIx::Class。您应该评估切换到此的成本。

您可能会发现您想要完全重写，以旧代码作为参考平台。这可能比您预期的要少得多。但是，从一些玩具网站开始，以了解您决定使用的任何框架/orm/模板。

【讨论】：