“Restful”Java WEB MVC框架
好吧，我知道有类似的线程，但我相信这是一个独特的。 首先，我来自C ++桌面开发世界，如果我没有得到所有的术语，我都会对我非常不满。
我正在开发的应用程序将是“响应式”，进行异步通信并来回传递大量JSON。
我需要一个支持的Java MVC WEB框架
1）最小量的BLOAT和“幕后魔法”。 对于任何框架，总是在框架功能与复杂性之间进行权衡。 但是，当我面临问题并且必须“打架”（时间总是来临）的时候，我希望这是一场公平的战斗。 最大限度地减少框架的规模增加了公平对抗的可能性。
2）原生RESTFUL支持 。 即路由html动词并执行内容协商。
3）直接支持处理JSON 。 使用我选择的任意json处理器，即jackson或gson等。
4）直截了当的坚持支持 ，例如JPA等
5）一些模板系统 ，例如freemarker，velocity等
6）支持“基于角色”的安全性的本地认证/授权安全方案，或与弹簧安全性轻松集成
以上所有内容都应该被整合到框架中。 不是在一些第三方用户贡献的模块中，当框架的新版本出现时，模块就会消失。
我坐了一天，试验并找到以下候选人
Spring MVC 3
1）为了在Spring MVC 3中获得众所周知的“Hello World”示例，我需要以下jar包：
最后在xml文件“dispatcher-servlet.xml”中定义一些定义。 我不知道这是否说明BLOAT或幕后魔法太多。 但它并没有给我一种温暖和模糊的感觉，可以控制自己
2）Spring 3支持这一点，从例子中我看到它看起来不太讨厌
3）支持，但从（2）中的链接，似乎处理JSON仅限于使用杰克逊库。 至少如果你想使用神奇的注释进行内容协商。
引用：
“Spring MVC委托HttpMessageConverter进行序列化，在这种情况下，Spring MVC调用一个基于Jackson JSON处理器构建的MappingJacksonHttpMessageConverter，当您在Jackson中使用mvc：annotation-driven配置元素时，会自动启用该实现呈现在你的类路径中。“
警告信号的位对我来说。 我想对我使用的JSON处理器有明确的程序控制。 也许我在这里错过了一些东西。 这在我的书中被认为是不必要的“幕后魔法”
4）是的
5）是的
6）是的
Play框架
1）版本1.2在我的磁盘上重88.5 MB。 不会在servlet容器中运行，因此，与春天相比，获得Hello World示例和运行非常容易，在那里甚至可以找出我需要的那些罐子被秘密保护。 很明显，幕后发生了很多事情。 我想所有我能希望的是，它不会超过它所能做的。 这个结论是合理的。 但是，当我有一天必须打架时，我会在抵达时死去吗？ 谁知道...
2）是的，它做得很高雅。 竖起大拇指。
3）是的，但它使用盖子下的gson。 再次，为什么我不能以编程方式控制这个？ 幸运的是，可以传递任意序列化程序来覆盖默认值。 我认为该参数映射到播放renderJSON（）本机函数的第二个参数。 所以玩半场大拇指传球。
4）是的。 有一个JPA模块
5）是的。 使用groovy。 我没意见。
6）应该可以通过组合安全模块和死锁模块。 不知道它对抗弹簧安全有多好。 我没有看到任何内置的密码加密和类似的支持。 并且不知道有多难（如果可能的话），那就是与弹簧安全相结合。 不知道我是否会舒适地部署敏感数据并依靠这个游戏！ 安全框架。 可能需要在它上面建立一些东西。
的Restlet
也许是一个特殊的候选人，因为它被用于“不安定的网络服务”。 但对于我的观点（1） - （6）和我的类型的应用程序，大多数用户交互是异步的，这似乎是一个很好的选择。 我可以在静态资源或动态生成的内容上运行它，并吐出任何内容类型。
1）Restlet 1.1.1约为54 MB。 浏览hello world示例。 我喜欢没有XML文件。 就像玩它有自己的服务器（码头连接器）。 你好世界的例子看起来非常干净和容易。
2）是的，这种方法非常“程序化”
3）是的，但似乎只能通过杰克逊扩展模块。 考虑到这个框架的程序性质，似乎可能还有其他选择，但我没有在文档或用户组论坛中找到任何内容。
4）将自己形容为“坚持不懈”。 好吧，我想这很好。 但是我想坚持下去，而不是重新发明自己的管道。 或者至少我想要一点点如何表明它可以通过一些努力来完成。 有一个第三方jpa模块但它建立在restlet 1.0上。 尽管Restlet有一个弹簧模块，所以也许我可以与弹簧持久性材料整合在一起......
5）是的，有一个freemarker扩展
6）有一个本地计划。 用拳头一眼，并不像春天的安全那样“富有”。 再次，也许我可以整合？
概要
Spring MVC 3 ：支持所有的需求，可能除了（1）。 我唯一担心的是它看起来很复杂，而且我得到了一种模糊不愉快的感觉，没有被控制。 随着我的应用程序的增长，我真的不希望被框架“陷入困境”。
玩 ：非常愉快的经历。 甚至乐趣。 如果只有安全方案更加先进，或者如果我至少能够与Spring安全相结合（并找到有关如何做到这一点的文档）
Restlet ：由于某种原因，这个框架引起了我的共鸣。 程序化方法引发了一种控制感。 但是，如果我不能以一种轻松的方式做出坚持，那么这是不行的 。 无法真正理解为什么这不是内置的。不是每个人都需要这个吗？
干杯
Spring和Play之间的比较现在已经过时了，因为Play 2.0已经在Scala中重写了，几乎在所有可能的方式中都更好。
检查出来：http://www.playframework.org/
我只能在这里发言。
当我去年被迫将Spring用于非REST项目时，我受到了折磨。 我不仅仅有几天的时间来掌握基础知识，我不喜欢它所做的所有“魔术”，也不熟悉IoC原则。
但它在我身上增长。 它也在我身上快速增长。 从那以后，我使用Spring来处理各种Web项目，其中包括公开RESTful API的项目。
从我的角度来看，Spring的优势在于：a）它实际上非常轻量级，一旦配置好配置后通常不会出现问题，b）提供示例和优秀社区以获得支持。c）做REST非常简单，一旦你得到你的配置正确，d）一个API设计，使神的欢呼哭泣，和e）IoC是改变生活。
说起你对膨胀的担忧......我已经使用了其他的Java Web框架，而Spring是他们所有IMO中最不胖的。 它可能看起来很多，但事实并非如此。 与Struts和Seam相比（这两者我仍然有恶梦），Spring与膨胀是对立的。 此外，IoC将让您无需编写大量样板文件即可离开，从而使您的应用程序不那么笨拙。
你提到你不想随着你的应用程序的增长而陷入僵局。 这不会发生在春天，我向你保证。 它的设计目的是避免使用任何一个框架。 你的代码 - 如果设计正确的话 - 可能会在未来出现其他问题，导致Spring并没有大量的诅咒和冲击。 它支持惯例而不是配置，这意味着常用的东西应该可以在没有修补太多的情况下运行。 对于那些离开墙壁的东西，它会给你足够的绳索来吊起你自己。
总之，我会高度考虑Spring。
我可以推荐的两个是RESTlet 2.x，我在每个项目中都使用它。 我正在考虑在即将开展的项目中使用RESTEasy。
我喜欢RESTlet的是所有的路由都在一个地方。 它功能非常丰富。
我不喜欢RESTEasy，而且我没有深入研究过，注释的所有路由都遍布在每种方法的代码基础上，可能是许多类。 没有将它们全部集中在一个地方，将会使可维护性变得更加困难。
为什么我仍在考虑RESTEasy，每个类有多个GET方法可能会减少RESTlet中可能发生的resource类爆炸。
两者都符合JAX-RS标准，如果这一点很重要，并且其中任何一个在时间和功能上都是可靠的投资。
至于模板，使用StringTemplate，远离FreeMarker之类的东西，它们只会导致可维护性的痛苦世界。
链接地址: http://www.djcxy.com/p/56925.html