“Restful”Java WEB MVC框架

我正在开发的应用程序将“响应”,进行异步通信并来回传递大量 JSON.

我需要一个支持的Java MVC WEB框架

1)BLOAT的最小数量和“幕后魔术”.对于任何框架,总是在框架功能与复杂性之间进行权衡.但是,当我遇到问题并且必须“打击框架”(并且那个时间总是来临)的时候,我希望它是一场公平的斗争.最小化框架的庞大规模增加了公平战斗的可能性.

2)原生RESTFUL支持.即路由html动词并执行内容协商.

3)直接支持处理JSON.使用我选择的任意json处理器,即jackson或gson e.t.c ..

4)直接的持久性支持,例如JPA e.t.c.

5)一些模板系统,例如freemarker,velocity e.t.c.

6)本机认证/授权安全方案,支持“基于角色”的安全性或与弹簧安全性轻松集成

以上所有内容都应该整合到框架中.不是在某个第三方用户贡献的模块中,当新版本的框架出现时,该模块就会消失.

我坐了一天,试验并找到了以下候选人

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”.我不知道是不是说BLOAT或幕后魔术太多了.但它并没有给我一种温暖而模糊的感觉,因为它可以控制自己

2)Spring 3支持这个,从examples我看到它看起来不太讨厌

3)支持,但是从(2)中的链接看来,处理json似乎仅限于使用jackson库.至少如果你想使用魔术注释进行内容协商.

引用：

“Underneath the covers,Spring MVC delegates to a HttpMessageConverter to perform the serialization. In this case,Spring MVC invokes a MappingJacksonHttpMessageConverter built on the Jackson JSON processor. This implementation is enabled automatically when you use the mvc:annotation-driven configuration element with Jackson present in your classpath.”

对我来说是一个警告信号.我想对我正在使用的JSON处理器有明确的编程控制.也许我在这里遗漏了一些东西.这在我的书中被认为是不需要的“幕后魔术”

4)是的

5)是的

6)是的

玩框架

1)版本1.2在我的磁盘上重88.5 MB.不在servlet容器中运行,所以获得hello world示例并且运行与spring相比很容易,即使找到我需要哪些罐子也是保密的.很明显,很多东西都发生在幕后.我想我所能希望的是它没有做到比它更多.而且这种结构是理智的.但是,当我有一天必须与框架作斗争时,我会在抵达时死亡吗？谁知道…

2)是的,它做得很优雅.竖起大拇指.

3)是的,但它在封面下使用gson.再次,为什么我不能以编程方式控制它？幸运的是,可以将任意序列化程序传递给gson来覆盖默认值.我认为该参数映射到play renderJSON()本机函数的第二个参数.因此,半个拇指向上传球.

4)是的.有一个JPA模块

5)是的.使用groovy.我没意见.

6)应该可以通过组合安全和死锁模块来实现.不知道它与弹簧安全性的对比如何.我没有看到任何内置的密码加密支持等.并且不知道与弹簧安全集成有多困难(如果可能的话).不知道我是否愿意部署敏感数据并依赖于游戏！安全框架.可能必须在它之上构建一些东西.

的Restlet

也许是一个特殊的候选人,因为它被用于“不安分的网络服务”.但对于我的观点(1) – (6)和我的大多数用户交互是异步的应用程序类型,它似乎是一个很好的选择.我可以在静态资源或动态生成的内容上运行它并吐出任何内容类型.

1)Restlet 1.1.1约为54 MB.看看你好世界的例子.我喜欢缺少XML文件.就像玩它有自己的服务器(jetty连接器).你好世界的例子看起来非常简洁.

2)是的,这种方法非常“程序化”

3)是的,但似乎只是通过jackson extension module.鉴于该框架的程序性,似乎有其他选项,但我没有在文档或用户组论坛中找到任何内容.

4)将自己描述为“持久性不可知”.好的,我觉得这很好.但我想坚持下去,而不是自己重新发明管道.或者至少我想要一些小的方法来表明它可以通过一些努力来完成.有一个第三方jpa模块但它建立在restlet 1.0上. Restlet有一个弹簧模块,所以也许我可以整合弹簧持久性的东西……

5)是的,有一个freemarker扩展名

6)有一个原生计划.乍一看,并不像春天安全那样“富裕”.再说一次,也许我可以整合？

摘要

Spring MVC 3：支持所有要求,可能除了(1)之外.我唯一关心的是它似乎很复杂,我得到一种模糊不愉快的感觉,就是不能控制.随着我的应用程序的增长,我真的不希望以后被框架“陷入困境”.

玩：非常愉快的经历.甚至有趣.如果只有安全方案更先进,或者我至少可以与spring安全集成(并找到有关如何执行它的文档)

Restlet：出于某种原因,这个框架引起了我的共鸣.程序化方法引起了一种控制感.但如果我不能以一种轻松的方式坚持下去,那就不行了.无法理解为什么没有内置.不是每个人都需要这个吗？

>使用上述任何框架的人说的是什么？
>我的观察是否准确？
>我是否遗漏了应该在这里的框架？
>替代品？