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

hou*_*ack 5 dependencies frameworks ruby-on-rails catalyst

我最近告诉一位朋友,我开始学习Catalyst(Perl),他相当强调,因为Catalyst有很多依赖,所以我应该使用类似Rails的东西.

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

我会恢复我的Catalyst教程,直到我得到一些多汁的回复.:-)

jro*_*way 7

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

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

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


小智 6

这是我之前看过的帖子.我一直想写一篇关于它的文章,并最终这样做了.

它在这里:独立的谎言

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

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

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


Dav*_*ith 2

当组件之间存在版本依赖性时,如果您被迫在依赖组件的兼容版本可用之前升级一个组件(例如,出于安全原因),您可能会发现自己陷入了一种无法工作的情况。

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

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

Rails 也没有摆脱这个问题。每发布一个新的 Ruby 版本,都会争先恐后地更新如何构建数据库驱动程序等说明。

公平地说,随着时间的推移,这个问题已经趋于“更好”,尽管道路上充满了坎坷。

  • 理论上是正确的,但不适用于 Catalyst。Catalyst 的大多数依赖项都是专门为 Catalyst 编写的,并且由维护 Catalyst::Runtime 的同一组维护。如果依赖项出现问题并破坏了其他依赖项,我们将同时释放所有内容。然而,这种情况从未发生过。 (2认同)
  • 另一件需要注意的事情是 Perl 模块版本通常非常向后兼容 - 因此 Catalyst 不依赖于 Some::Module 版本 3,而是依赖于 Some::Module 版本 >=3。另一方面,这意味着虽然 Catalyst 安装了许多模块组合,但不能保证您的组合之前已被尝试过。另一方面,Catalyst 及其所有依赖的 Perl 模块附带了大量测试,这些测试在您安装时会自动运行。 (2认同)