框架比较分析

首先让我说我不在Devoxx 2010中。但是，我从Matt Raible的Comparing JVM Web Frameworks中听到了。 与许多人一样，当我阅读最终结果时 ，令我感到惊讶的是，我最喜欢的框架（对我而言是Vaadin ）没有排名第一。 我经历了悲伤的各个阶段 ，然后终于意识到演示本身比矩阵有趣得多。 问题不在于矩阵，而在于创建矩阵的方法。 不要误会我：马特非常勇敢地走进光明并展开辩论。 但是，恕我直言，我想提出几点。 请注意，即使是Matt的工作也是本文的火花，对于旨在对框架进行排名的每个矩阵也可以这样说。

号码

矩阵使用素数和冷数来计算等级。 因此，对结果有一种科学的感觉。 但这仅仅是一种感觉。 因为每个等级都会受到威胁。 您如何分配它们？ 让我们采用多语言标准：当框架支持Java，Grails和Scala时，似乎给出了最高等级（1）。 据我了解，Struts具有JAR格式，可以从任何JVM语言中调用。 那么为什么Struts的0.5呢？

另一方面，我个人会为风险框架的程度将全新框架（例如Play和Lift）分配为0。 我还将对JSF 2给出平坦的0。这完全取决于您的愿景。

范围

这很简短：“开发人员的可用性”和“工作趋势”标准之间有什么区别？ 前者是快照，后者是趋势吗？ 那么，为什么“插件/附件”或“文档”标准没有得到相同的待遇？

标准重量

为什么所有标准都被赋予相同的权重？ 如果我不在乎我的应用程序是否可以轻松本地化怎么办？ 如果我不必支持手机怎么办？ 如果可伸缩性不是问题怎么办？ 赋予标准权重应该给出完全不同的结果。 现在的问题在于分配正确的权重。 我们回到了第一点。

上下文，上下文和更多上下文

我以前的文章建议人们在上下文中思考 。 这是事实：如果您位于芬兰，那么我想打赌“工作趋势”或“开发人员可用性”对于想要启动Vaadin项目的管理人员来说应该不是问题。 相比之下，在瑞士，我不了解很多人掌握（甚至不了解）JSF 2或Spring MVC。

要求

我不认为任何人都应该选择一个框架来完成。 考虑一下：如果选择Flex，则将无法在iPhone上运行，而如果选择传统方法，则将无法脱机运行应用程序。 不同的需求意味着您应该对可能的用例进行分类，并为每个用例准备好框架。

我自己的经验

当我们不得不选择一个JavaScript框架时，我面临着同样的任务。 我们在候选框架上做了一篇书面文章，列出了每个感知到的利弊，但自愿未对它们进行排名。 恕我直言，我相信这足以让您根据自己的需求和上下文选择正确的应用程序框架。

结论

在持久层上，Hibernate或EclipseLink是领导者。 对于依赖注入，Spring是事实上的标准。 对于表示层，问题不在于缺少选择，而在于您有很多选择。 因为它们中的许多都有优缺点。 在等待将解决我们所有问题的完美框架之前，我们应该为最适合当前需求和环境的框架做好准备。

翻译自: https://blog.frankel.ch/critical-analysis-of-frameworks-comparison/