Dancer vs Catalyst [Perl Web框架]

Question

你对这两个问题都怎么看？我开始读一本关于Catalyst的书，发现它与Dancer相比相当复杂。因此，现在我尝试了一下Dancer，它看起来更容易学习，也更“人性化”。

Answer 1

这是一个比较主观的问题，但我会尝试以客观的方式给你一个答案。首先，免责声明：我是舞者开发团队的一员，所以我的观点当然应该被认为是有偏见的:)

Catalyst的使用比Dancer更广泛，因此它背后有更多的社区支持-如果你想寻找有经验的承包商，比如说，你更有可能找到使用过Catalyst的开发人员。因此，如果您正在寻找商业支持，这将是选择Catalyst的一个很好的理由。

Dancer是一个更年轻的项目，更多地针对较小的项目，使启动和运行变得快速和容易，并试图远离你的方式。然而，这并不是说Dancer不适合更大的项目，同样的习惯意味着你可以用适合你的方式来组织你的项目。

然而，它已经获得了很多支持，在IRC和邮件列表上有越来越多的乐于助人的用户和开发人员，而且越来越多有用的插件一直在发布。与Catalyst一样，Dancer的设计让你可以挑选你喜欢的模板引擎，会话存储后端等，如果你需要的话，可以很容易地通过编写你自己的插件来扩展框架。

要查看用户对舞者的评价，请参阅新网站主页底部的部分：http://www.perldancer.org/

为了展示其他选项，还有另一个现代Perl web框架Mojolicious，它最近越来越受欢迎。

Answer 2

我认为David的评论是非常准确和出色的。然而，作为一个在这两个方面都做过开发但不是开发人员的人，也许我可以稍微客观一点(和技术上的)区别是什么。

这两个框架都提供了Web MVC范例的变体。

Catalyst的主要抽象层是控制器。Catalyst期望您以某种逻辑方式将单独的逻辑分解到单独的包中(登录代码放在这里，注册代码放在那里，搜索功能放在这里)。如果你有一个程序员团队，这会工作得非常好，因为你们每个人都可以处理不同的文件，而不是在合并过程中互相踩在一起。Catalyst提供了许多工具来使控制器逻辑可扩展和灵活，我认为最好的例子是链式操作，它允许您为任何给定的请求拆分和构建复杂的流程。缺点是，将业务逻辑放到控制器中变得非常诱人，最终在控制器中得到非常胖的逻辑，而(理论上)它属于模型。

Dancer的主要抽象层是Route。我对Dancer的经验是，这会导致更小的应用程序。我在这里的部分经验是，我在Catalyst中处理过数千个line应用程序，但我还没有编写过超过200行的Dancer应用程序(范围要小得多)。然而，我认为这种经验是正确的。push in Dancer保持了非常精简的控制器逻辑，因为它没有Catalyst那样的管理复杂行为的工具。

老实说，我很享受在这两家公司工作的乐趣。它们都提供了关于编写web应用程序应该是什么的不同观点。如果有足够的时间和兴趣，我最终会建议你同时学习这两种方法。

Answer 3

Catalyst提供了与Dancer相同的抽象，Dancer的优势或者更确切地说是Catalyst的弱点，或者更确切地说，是Catalyst的弱点在于Catalyst如何迫使开发人员遵守Perl OO最佳实践和MVC设计模式。在做了一段时间的webapps之后，这一切都会变得显而易见。