ruby-on-rails - 使用具有大量依赖项的框架有什么问题？

Question

我最近告诉一个朋友，我开始学习 Catalyst (Perl)，他相当强烈地强调，因为 Catalyst 有如此多的依赖项，所以我应该改用 Rails 之类的东西。

有很多依赖项不是一件好事吗？这不是表示大量代码重用吗？我知道安装框架可能需要更多的努力，但还有其他缺点吗？

我将继续我的Catalyst 教程，直到我得到一些有趣的回应。:-)

Answer 1

这并没有什么特别的错误。Catalyst 的优势在于它的部件可以被不使用所有 Catalyst 的人使用。这意味着有更多的眼睛在关注关键部分并修复其中的错误。

我听到的最大的抱怨是，在安装 Catalyst 时，看着所有这些消息在 CPAN shell 中经过是很烦人的。解决方案是在开始时利用操作系统的包管理器。在 Debian 上，apt-get install libcatalyst-perl在没有安装其他 Perl 模块的机器上安装需要 15 秒。15 秒。（简单的 CPAN 安装也不难，但我猜标准的 CPAN shell 会问你很多愚蠢的问题，这会让新手望而却步。）

不用担心依赖关系，有很好的工具来管理它们，它们使框架更强大、更灵活。

Answer 2

这是我以前看过帖子的主题。我一直想写一篇关于它的文章，最后还是这样做了。

它在这里：独立的谎言

我鼓励你阅读它。不过，要点很简单。问题是错误的。这不是“您使用具有大量依赖项的应用程序或框架，还是没有依赖项的应用程序或框架？”

它是：“你使用的应用程序或框架有很多外部依赖项，还是试图在内部完成所有这些依赖项？”

接下来的问题是“你真的相信编写这个框架的人了解处理网络请求所需完成的每项任务的每一个微小细节的每一个细微差别吗？”

Answer 3

当组件之间存在版本依赖关系时，如果您在依赖组件的兼容版本可用之前被迫升级一个组件（例如，出于安全原因），您可能会发现自己陷入了无法工作的境地。

这假设您首先可以进入工作状态。如果您尝试使用所有依赖项的当前版本，您可能会发现它们无法配合使用。

依赖项的数量越多，风险就越大。

Rails 也不是没有这个问题。对于每个新的 Ruby 版本，都会争先恐后地更新有关如何获取（例如）构建数据库驱动程序的说明。

公平地说，随着时间的推移，这个问题已经趋于“更好”，尽管道路上有颠簸。

Answer 4

我个人的经验是，您拥有的依赖项越多，您必须跟踪的版本控制就越多，这可能会导致噩梦般的情况。特别是，更新一个依赖项（例如，由于您想要修复的错误）可能会给您带来与其他依赖项的兼容性问题。例如，我个人遇到的情况是 gcc 4.0.3 使用 foo 但不使用 bar（依赖于 foo），而 gcc 4.0.5 使用 bar 但不使用 foo。幸运的是，4.0.2 工作。

此外，更多的依赖项往往指向“弗兰肯斯坦的怪物”产品，这些产品由未预先设计用于一起玩的部件制成。一个集成良好的框架旨在发挥良好和一致的作用。当然，这可以通过适当地包装差异来解决。