"Restful" Java WEB MVC 框架

Question

我正在开发的应用程序将是“响应式”的，进行异步通信并传递大量 JSON。 我需要一个支持以下功能的 Java MVC WEB 框架： 1）最小化臃肿和“幕后魔法”。任何框架都存在框架功能与复杂性之间的权衡。但是，当我面临问题并不得不“与框架作斗争”时（这种情况总会出现），我希望这是一场公平的战斗。最小化框架的大小可以增加公平战斗的可能性。 2）本地 RESTFUL 支持。即路由 HTML 动词并执行内容协商。 3）直接支持处理 JSON。使用我选择的任意 JSON 处理器，例如 jackson 或 gson 等。 4）简单的持久性支持，例如 JPA 等。 5）一些模板系统，例如 freemarker、velocity 等。 6）原生身份验证/授权安全机制，支持“基于角色”的安全性或轻松集成 spring 安全性。

以上所有内容都应该集成在框架中，而不是某些第三方用户贡献的模块中，当框架的新版本出现时它们就会消失。

我花了一天时间进行实验，并找到了以下候选者：

Spring MVC 3

1）要在Spring MVC 3中运行传统的“Hello World”示例，我需要以下jar包：

• org.springframework.beans-3.1.0.RELEASE.jar
• org.springframework.expression-3.1.0.RELEASE.jar
• org.springframework.asm-3.1.0.RELEASE.jar
• org.springframework.context-3.1.0.RELEASE.jar
• org.springframework.core-3.1.0.RELEASE.jar
• org.springframework.web-3.1.0.RELEASE.jar
• org.springframework.web.servlet-3.1.0.RELEASE.jar

最后，在xml文件“dispatcher-servlet.xml”中有一些定义。我不知道这是否会导致程序膨胀或太多的幕后魔法。但它没有让我感到掌控感。

2) Spring 3支持此功能，从examples中看来，它看起来并不太复杂。

3) 支持，但从(2)中的链接看来，处理json似乎仅限于使用jackson库。至少如果您想使用内容协商的魔术注释的话。

引用:

"在底层，Spring MVC委托给HttpMessageConverter执行序列化。在这种情况下，Spring MVC调用基于Jackson JSON处理器构建的MappingJacksonHttpMessageConverter。当您在类路径中使用Jackson时，此实现会自动启用mvc:annotation-driven配置元素。"

对我来说有点警告信号。我希望能清楚地对所使用的JSON处理器进行编程控制。也许我在这里漏掉了什么。在我的书中，这就是不需要的“幕后魔法”。

4) 是的

5) 是的

6) 是的

Play Framework

1) 版本1.2在我的磁盘上占用了88.5 MB。它不在servlet容器中运行，因此与Spring相比，获取hello world示例并运行非常容易，而在Spring中，即使找出我需要哪些jar包也是神秘的。显然，在play中发生了很多事情。我想我能希望的就是它不会做超出必要的事情。并且架构是合理的。但是，当我有一天必须与框架作斗争时，我是否会死亡？谁知道...

2) 是的，而且它非常优雅。点赞。

3) 是的，但它在幕后使用gson。同样，为什么我不能通过编程方式控制这个？幸运的是，可以向gson传递任意序列化程序以覆盖默认值。而且我认为该参数映射到play renderJSON()本机函数的第二个参数。所以play只通过了一半。

4) 是的。有一个JPA模块

5) 是的。使用Groovy。对我来说很好。

6) 通过组合安全和死锁模块应该是可能的。不知道它在与Spring Security相比如何。我没有看到任何内置支持密码加密等功能。也不知道与Spring Security集成有多难（如果可以的话）。不知道是否愿意部署敏感数据并依赖Play!框架进行安全性保障。可能需要在其上构建一些东西。

Restlet

作为“无休止Web服务”的营销对象，Restlet可能是一个奇特的候选者。但对于我的1-6点和大多数用户交互都是异步的应用程序类型，它似乎很适合。我可以在静态资源或动态生成的内容上运行它，并输出任何内容类型。

1) Restlet 1.1.1大约为54 MB。浏览了hello world示例。我喜欢没有XML文件的方式。就像play一样，它有自己的服务器（jetty连接器）。hello world示例看起来非常干净和简单。

2) 是的，方法非常“编程化”。

3) 是的，但似乎只能通过jackson扩展模块实现。考虑到这个框架的编程性质，很可能还有其他选项，但我在文档或用户组论坛中没有找到任何信息。

4) 自称为“持久性无关”。好吧，我想这很好。但我想要持久化而不是自己重新发明轮子。或者至少我希望有一个小教程，展示它可以通过一些努力来完成。有一个第三方jpa模块。但它是建立在restlet 1.0之上的。Restlet有一个spring模块，所以也许我可以集成spring持久性东西...

5) 是的，有一个freemarker扩展

6) 有一个本地方案。乍一看，不如spring security“丰富”。再次，也许我可以集成？

总结

Spring MVC 3: 支持所有要求，可能除了（1）。唯一的担忧是它似乎很复杂，我有一种模糊的不掌控感。我真的不想在我的应用程序增长后被框架所束缚。 Play: 非常愉快的体验。甚至很有趣。如果安全方案更先进，或者我至少可以与Spring Security集成（并找到如何做到这一点的文档），那就好了。 Restlet: 出于某种原因，这个框架让我感觉很好。编程方法引发了一种控制感。但如果我不能以某种简单易行的方式进行持久化，那么就不行了。我真的不明白为什么这不是内置的。难道不是每个人都需要吗？

• 使用过上述任何一个框架的人有什么看法？
• 我的观察准确吗？
• 我是否遗漏了应该在此处的框架？
• 其他选择？

- user1119651

---

如果你不仅限于Java，而且也考虑Groovy，那么你可能想看一下Grails。Grails - Robin

Answer 1

现在比较Spring和Play已经过时了，因为Play 2.0已经用Scala重新编写，在几乎所有方面都更好。

请查看：http://www.playframework.org/

- fracca

Answer 2

我只能就Spring发表意见。

去年，当我被迫在一个非REST项目中使用Spring时，我感到很不爽。我不仅只有几天时间来学习基础知识，而且我不喜欢它所做的所有“魔法”，也不熟悉IoC原理。

但是它成为了我的挚爱。它对我来说增长得相当快。从那以后，我已经将Spring用于各种Web项目，包括公开RESTful API的项目。

我认为Spring的优点是：a）一旦你配置好了，它实际上非常轻巧，并且通常不会妨碍你；b）有大量的示例和支持的社区；c）一旦你正确配置了，REST变得非常简单；d）API设计让众神为之欢欣鼓舞；e）IoC改变人生。

针对您对膨胀的担忧...我曾经使用过其他Java Web框架，而在我看来，Spring是它们中最不臃肿的。它可能看起来很多，但实际上并不是这样。与Struts和Seam相比（这两个我仍然做恶梦），Spring是反膨胀的。此外，IoC能够让您不必编写大量的样板代码，使您的应用程序不那么臃肿。

你提到你不想让框架在应用程序增长时变得复杂。我向你保证，这种情况不会发生在Spring中。它被设计成不干扰你的工作，并且让你不依赖于任何一个框架。如果你的代码设计正确，将来可以轻松地将Spring替换为其他框架而不需要太多的抱怨和头痛。它更倾向于约定优于配置，这意味着常见的东西应该能够直接使用，而不需要过多地调整。对于那些比较特殊的需求，它也给了你足够的自由度。

总之，我强烈建议考虑使用Spring。

- The Awnry Bear

Answer 3

我可以推荐的两个是RESTlet 2.x，我在每个项目中都使用它。以及RESTEasy，我正在考虑在即将到来的项目中使用它。

我喜欢RESTlet的原因是所有路由都在一个地方。它非常功能丰富。

我不喜欢RESTEasy的原因是，我没有深入研究过它，但注释将所有路由散布在每个方法上，可能会出现许多类的代码库中。没有将它们放在一个地方，将使可维护性更加困难。

我仍在考虑RESTEasy的原因是，每个类有多个GET方法可能会减少在RESTlet中可能发生的resource类爆炸。

如果这很重要，两者都符合JAX-RS标准，任何一个都是时间和功能的可靠投资。

关于模板方面，请使用StringTemplate，避免使用像FreeMarker这样的工具，这只会导致维护难度加大。

- user177800