「Restful」Java WEB MVC框架

Question

好吧，我知道有類似的線程，但我相信這一個是不同的。首先，我來自C++桌面開發世界，如果我沒有把所有的術語都說得對，那麼這個世界就會如此光禿禿的。

我正在開發的應用程序將是「響應式」，做異步通信並來回傳遞大量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）爲了得到衆所周知的「Hello World」的例子並運行在Spring MVC 3，我需要下面的罐子：

• 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文件中的一些定義，「調度員的servlet .XML」。我不知道這是否說明BLOAT或幕後魔法太多。但它並沒有給在掌控之中somehwat我一個溫暖和模糊的感覺

2）彈簧3支持這一點，從examples只見它看上去並不是很討厭

3）支持的，但是從（2）中的鏈接，似乎處理json僅限於使用jackson庫。至少如果你想使用神奇的註釋進行內容協商。

報價：

「下面的封面，Spring MVC的委託給HttpMessageConverter進行序列化在這種情況下，Spring MVC的調用內置的傑克遜JSON處理器的MappingJacksonHttpMessageConverter此實現自動啓用。當你在類路徑中使用帶有Jackson的mvc：annotation-driven配置元素時。「

位警告信號對我來說。我想對我使用的JSON處理器有明確的程序控制。也許我在這裏錯過了一些東西。這有資格作爲不必要的 「幕後法寶」 在我的書

4）是的

5）是的

6）是

播放框架

1）1.2版本我的磁盤上重達88,5 MB。不會在servlet容器中運行，因此，與春天相比，獲得Hello World示例和運行非常容易，在那裏甚至可以找出我需要的那些罐子被祕密保護。很明顯，幕後發生了很多事情。我想所有我能希望的是，它不會超過它所能做的。這個結論是合理的。但是，當我有一天必須打架時，我會在抵達時死去嗎？誰知道...

2）是的，它是如此優雅。豎起大拇指。

3）是的，但它使用蓋子下的gson。再次，爲什麼我不能以編程方式控制這個？幸運的是，可以傳遞任意序列化程序來覆蓋默認值。我認爲該參數映射到播放renderJSON（）本機函數的第二個參數。所以玩半場大拇指傳球。

4）是的。有JPA模塊

5）是的。使用groovy。我沒意見。

6）應該可以通過組合安全模塊和deadbolt模塊。不知道它對抗彈簧安全有多好。我沒有看到任何內置的密碼加密和類似的支持。並且不知道有多難（如果可能的話），那就是與彈簧安全相結合。不知道我是否會舒適地部署敏感數據並依靠這個遊戲！安全框架。可能需要在它上面建立一些東西。

的Restlet

也許因爲它的銷售將用於「不安分的Web服務」一個奇特的候選人。但對於我的觀點（1） - （6）和我的類型的應用程序，大多數用戶交互是異步的，這似乎是一個很好的選擇。我可以在靜態資源或動態生成的內容上運行它，並吐出任何內容類型。

1）Restlet 1.1.1約爲54 MB。瀏覽hello world示例。我喜歡沒有XML文件。就像玩它有自己的服務器（碼頭連接器）。你好世界的例子看起來非常乾淨和容易。

2）是的，這種方法是非常 「綱領性」

3）是的，但它似乎只能通過jackson extension module。考慮到這個框架的程序性質，似乎可能還有其他選擇，但我沒有在文檔或用戶組論壇中找到任何內容。

4）自我描述爲「堅持不懈」。好吧，我想這很好。但是我想堅持下去，而不是重新發明自己的管道。或者至少我想要一點點如何表明它可以通過一些努力來完成。有一個第三方jpa模塊但它建立在restlet 1.0上。的Restlet有一個彈簧組件的，所以也許我可以用彈簧持久性的東西整合...

5）是的，有一個FreeMarker的擴展

6）對該原生方案。用拳頭一眼，並不像春天的安全那樣「富有」。再次，也許我可以整合？

內容

彈簧MVC 3：支持所有的要求，可能與除外（1）。我唯一擔心的是它看起來很複雜，而且我得到了一種模糊不愉快的感覺，沒有被控制。隨着我的應用程序的增長，我真的不希望被框架「陷入困境」。

玩：非常愉快的經歷。甚至樂趣。如果只有安全計劃是更先進的，或者如果我至少可以使用Spring Security集成（並找到如何做到這一點的文件）

的Restlet：出於某種原因，這個框架契合了我。程序化方法引發了一種控制感。 但是，如果我不能堅持一些輕鬆的方式，那麼這是一個不行的。無法真正理解爲什麼這不是內置的。不是每個人都需要這個嗎？

• 什麼說使用上述任何框架的人？
• 我的觀察結果是否準確？
• 我遺漏了一個應該在這裏的框架嗎？
• 替代品？

乾杯

Answer 1

我只能在這裏說話的春天。

去年當我被迫將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。

Answer 2

我可以推薦的兩個是RESTlet 2.x，我在每個項目中都使用它。而我正在考慮在即將推出的項目中使用RESTEasy。

我對RESTlet的喜愛是所有的路由都在一個地方。這是非常feature rich。

我不喜歡RESTEasy，而且我還沒有深入研究過它，註釋的所有路由都散佈在每種方法的代碼基礎上，可能是許多類。沒有將它們全部集中在一個地方，將會使可維護性變得更加困難。

爲什麼我仍在考慮RESTEasy，每個類有多個GET方法可能會減少在RESTlet中可能發生的resource類爆炸。

兩者都符合JAX-RS標準，如果這一點很重要，並且其中任何一個都是對時間和功能的可靠投入。

至於模板，請使用StringTemplate，遠離FreeMarker之類的東西，它們只會導致可維護性的痛苦世界。

Answer 3

Spring和Play之間的比較現在已經過時了，因爲Play 2.0已經在Scala中重寫了，幾乎在所有可能的方式中都更好。

檢查出來：http://www.playframework.org/