“Restful” Java Web MVC framework

The application I'm developing will "respond", communicate asynchronously and pass a lot of JSON back and forth

I need a supported Java MVC web framework

1) The minimum number of bloats and "behind the scenes magic" For any framework, there is always a trade - off between framework functionality and complexity But when I have a problem and have to "hit the frame" (and that time always comes), I hope it is a fair fight Minimizing the size of the framework increases the likelihood of a fair fight

2) Native restful support That is, route HTML verbs and perform content negotiation

3) It directly supports the processing of JSON Use any JSON processor I choose, Jackson or gson e.t.c

4) Direct persistence support, such as JPA e.t.c

5) Some template systems, such as freemaker, velocity, e.t.c

6) Native authentication / authorization security scheme, which supports "role-based" security or easy integration with spring security

All of the above should be integrated into the framework In a module not contributed by a third party user, the module will disappear when a new version of the framework appears

I sat all day, experimented and found the following candidates

Spring MVC 3

1) To start and run the well-known "Hello world" example in spring MVC 3, I need the following 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

Finally, there are some definitions in the XML file, "dispatcher - servlet. XML" I don't know if it means too much bloat or behind the scenes magic But it doesn't give me a warm and fuzzy feeling, because it can control itself

2) Spring 3 supports this. From examples, I can see that it doesn't look too annoying

3) Yes, but from the link in (2), it seems that JSON processing is limited to the Jackson library At least if you want to use magic annotations for content negotiation

quote:

It's a warning signal for me I want to have clear programming control over the JSON processor I'm using Maybe I missed something here This is considered unnecessary "behind the scenes magic" in my book

4) Yes

5) Yes

6) Yes

Play frame

1) Version 1.2 weighs 88.5 MB on my disk It doesn't run in the servlet container, so it's easy to get the Hello World sample and run it compared with spring. Even if I find which cans I need, it's confidential Obviously, a lot of things happen behind the scenes I think all I can hope for is that it doesn't do more than it does And this structure is rational But when I have to fight the frame one day, will I die on arrival? Who knows

2) Yes, it's done gracefully Give a thumbs up

3) Yes, but it uses gson under the cover Again, why can't I control it programmatically? Fortunately, any serializer can be passed to gson to override the default I think this parameter maps to the second parameter of the play renderjson () native function Therefore, half a thumb passes the ball up

4) Yes There is a JPA module

5) Yes Using groovy I have no problem

6) It should be possible to achieve this by combining security and deadlock modules I wonder how it compares with the safety of the spring I don't see any built - in password encryption support, etc And I don't know how difficult it is to integrate with spring safety (if possible) I don't know if I am willing to deploy sensitive data and rely on the game! Safety framework You may have to build something on it

Restlet

It may be a special candidate because it is used for "restless network services" But for my point of view (1) - (6) that most of my user interactions are asynchronous application types, it seems to be a good choice I can run it on static resources or dynamically generated content and spit out any content type

1)Restlet 1.1. 1 is approximately 54 MB Look at the example of Hello world I like missing XML files It's like playing with its own server (jetty connector) The example of Hello world looks very concise

2) Yes, this method is very "procedural"

3) Yes, but it seems only through Jackson extension module Given the procedural nature of the framework, there seem to be other options, but I didn't find anything in the documentation or user group forums

4) Describe yourself as "persistent unknowable." OK, I think it's good But I want to stick to it instead of reinventing the pipe myself Or at least I want some small ways to show that it can be done with some effort There is a third-party JPA module, but it is built on restlet 1.0 Restlet has a spring module, so maybe I can integrate something with spring persistence

5) Yes, there is a freemaker extension

6) There is an original plan At first glance, it is not as "rich" as spring security Again, maybe I can integrate?

abstract

Spring MVC 3: supports all requirements except (1) My only concern is that it seems very complex. I get a vague and unpleasant feeling that I can't control it As my application grows, I really don't want to be "stuck" by the framework in the future

Play: a very pleasant experience Even interesting If only the security solution is more advanced, or at least I can integrate with spring security (and find the documentation on how to execute it)

Restlet: for some reason, this framework resonates with me The programmed method gives rise to a sense of control But if I can't stick to it in an easy way, I can't I can't understand why there is no built-in Doesn't everyone need this?

>What do people who use any of these frameworks say? > Is my observation accurate? > Did I miss the framework that should be here? > succedaneum?

Solution

The comparison between spring and play is now outdated because play 2.0 has been rewritten in scala and is better in almost all aspects

have a look: http://www.playframework.org/

The content of this article comes from the network collection of netizens. It is used as a learning reference. The copyright belongs to the original author.
THE END
分享
二维码
< <上一篇
下一篇>>