使用具有大量依赖性的框架有什么问题？

Question

我最近告诉一位朋友我开始学习Catalyst（Perl）并且他非常强烈地强调，因为Catalyst有很多依赖性，所以我应该使用类似Rails的东西。

存在很多依赖关系不是一件好事吗？这不是表明很多代码重用吗？我知道安装框架可能需要付出更多努力，但是还有其他缺点吗？

我会恢复我的Catalyst tutorial，直到我得到一些多汁的回答。 ： - ）

Answer 1

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

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

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

Answer 2

这是我之前看过的帖子。我一直想写一篇关于它的文章，并最终完成了。

就在这里：The Lie of Independence

我鼓励你阅读它。但要点很简单。问题是错的。它不是'您使用具有大量依赖关系的应用程序或框架，还是没有它们的应用程序或框架？'

它是：'您是使用具有大量外部依赖关系的应用程序或框架，还是尝试在内部完成所有操作的应用程序或框架？

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

Answer 3

当组件之间存在版本依赖关系时，如果您在依赖组件的兼容版本可用之前被迫升级一个组件（例如，出于安全原因），则可能会发现自己处于非工作状态。< / p>

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

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

Rails也没有解决这个问题。每一个新的Ruby版本都会有一个争夺更新指令的争夺，比如建立数据库驱动程序。

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

Answer 4

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

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