"Restful" Java WEB MVC фреймворки - PullRequest
7 голосов
/ 28 декабря 2011

Разрабатываемое мной приложение будет «отзывчивым», будет выполнять асинхронную связь и передавать много JSON туда и обратно.

Мне нужна веб-инфраструктура Java MVC, поддерживающая

1) Минимальное количество BLOAT и "магия за кулисами".В любом фреймворке всегда есть компромисс между функциональностью фреймворка и сложностью.Но когда приходит время, когда я сталкиваюсь с проблемой и должен «бороться с рамками» (а это время всегда наступает), я хочу, чтобы это был честный бой.Минимизация размера каркаса увеличивает вероятность честного боя.

2) Родная поддержка RESTFUL .Т.е. маршрутизировать html-глаголы и выполнять согласование содержимого.

3) Простая поддержка обработки JSON .Использование произвольного процессора JSON по моему выбору, то есть Джексона или GSON и т. Д.

4) Прямая поддержка сопротивления , например, JPA и т. Д.

5) Некоторый наборсистемы шаблонов , например, freemarker, скорость и т. д.

6) Собственная аутентификация / авторизация схема безопасности с поддержкой безопасности на основе ролей ИЛИ Простая интеграция с пружинной безопасностью

Все вышеперечисленное должно быть интегрировано в структуру.Не в каком-то стороннем модуле, добавленном пользователем, который гаснет, когда появляется новая версия фреймворка.

Я сел на один день и экспериментировал и нашел следующих кандидатов

SpringMVC 3

1) Чтобы запустить общеизвестный пример "Hello World" в Spring MVC 3, мне потребовались следующие файлы 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 поддерживает это, и из примеров я видел, что это выглядит не слишком противно

3) Поддерживается, но из ссылки в (2) кажется, что обработка json ограничена использованием библиотеки Джексона.По крайней мере, если вы хотите использовать магические аннотации для содержания содержимого.

Цитата:

"Под крышками Spring MVC делегирует HttpMessageConverter для выполнения сериализации.В этом случае Spring MVC вызывает MappingJacksonHttpMessageConverter, построенный на процессоре JSON в Джексоне. Эта реализация включается автоматически при использовании элемента конфигурации, управляемого на основе mvc: annotation, когда Джексон присутствует в вашем пути к классам. "

Бит предупреждающего сигнала для меня.Я хотел бы иметь четкий программный контроль над тем, какой процессор JSON я использую.Может быть, я что-то здесь упускаю.Это квалифицируется как нежелательное "закулисное волшебство" в моей книге

4) Да

5) Да

6) Да

ВоспроизвестиFramework

1) Версия 1.2 весила 88,5 МБ на моем диске.Он не запускается в контейнере сервлетов, так что пример с hello world и бегать было легко, по сравнению с весной, когда даже выяснение того, какие банки мне нужны, было окутано тайной.Очевидно, что многое происходит за кулисами в игре.Я думаю, все, на что я могу надеяться, это то, что он не делает больше, чем должен.И эта архитектура здравомыслящая.Но когда я когда-нибудь буду сражаться с фреймворком, буду ли я мертв по прибытии?Кто знает ...

2) Да, и это так элегантно.Недурно.

3) Да, но он использует gson под крышками.Опять же, почему я не могу контролировать это программно?К счастью, можно передать произвольный сериализатор в gson, чтобы переопределить значение по умолчанию.И я думаю , что параметр отображается на второй параметр нативной функции play renderJSON ().Так что игра проходит с половиной большого пальца вверх.

4) Да.Имеет модуль JPA

5) Да.Использует заводной.Прекрасно для меня.

6) Должно быть возможно путем объединения модулей безопасности и засова.Не знаю, насколько хорошо он противостоит весенней безопасности.Я не вижу встроенной поддержки для шифрования пароля и тому подобного.И понятия не имею, насколько сложно (если вообще возможно) было бы интегрироваться с пружинной безопасностью.Не знаю, будет ли мне удобно развертывать конфиденциальные данные и полагаться на игру!рамки для безопасности.Вероятно, придется что-то построить поверх него.

Restlet

Возможно, это особый кандидат, поскольку он продается для использования в качестве "беспокойных веб-сервисов".Но для моих пунктов (1) - (6) и для моего типа приложений, в которых большая часть взаимодействия с пользователем асинхронна, это кажется хорошим решением.Я могу запустить его на статических ресурсах или динамически генерируемом контенте и выплюнуть любой тип контента.

1) Restlet 1.1.1 составляет около 54 МБ.Посмотрел пример Привет, мир.Мне понравилось отсутствие файлов XML.И так же, как играть, он имеет свой собственный сервер (разъемы причала).Пример Hello World выглядел очень чистым и легким.

2) Да, и подход очень "программный"

3) Да, но, похоже, только через модуль расширения Джексона .Учитывая программную природу этого фреймворка, представляется вероятным, что есть и другие варианты, но я ничего не нашел в документации или на форумах групп пользователей.

4) Описывает себя как "независимый от персистентности".Хорошо, это хорошо, я думаю.Но я хочу упорствовать и не изобретать сантехнику самостоятельно.Или, по крайней мере, я хочу немного показать, как это можно сделать с некоторыми усилиями.Существует сторонний модуль jpa, но он построен на рестлете 1.0.В Restlet есть модуль Spring, так что, возможно, я смогу интегрировать его с поддерживающими пружинами ...

5) Да, есть расширение freemarker

6) Для этого есть собственная схема.На первый взгляд, не такой «богатый», как весенняя охрана.Опять же, может быть, я могу интегрировать?

РЕЗЮМЕ

Spring MVC 3 : Поддерживает все требования, возможно, сисключение (1).Единственное, что меня беспокоит, так это то, что это кажется сложным, и у меня появляется смутное неприятное ощущение, что я не контролирую ситуацию.Я действительно не хочу, чтобы фреймворк «увязал» позже по мере роста моего приложения.

Play : Очень приятный опыт.Веселье даже.Если бы только схема безопасности была более продвинутой, или если бы я мог хотя бы интегрироваться с пружинной безопасностью (и найти документацию о том, как это сделать)

Restlet : Дляпочему-то эта структура нашла отклик у меня.Программный подход вызывает чувство контроля. Но если я не могу проявить настойчивость каким-то легкомысленным способом, тогда это не пойдет .Не могу понять, почему это не встроено. Разве это не всем нужно?

  • Что говорят люди, которые использовали любую из вышеперечисленных платформ?
  • Точны ли мои наблюдения?
  • Я пропустил рамки, которые должны быть здесь?
  • Альтернативы?

Ответы [ 3 ]

3 голосов
/ 23 апреля 2012

сравнение между Spring и Play теперь сильно устарело, так как Play 2.0 был переписан в Scala и улучшен практически всеми возможными способами.

Проверьте это: http://www.playframework.org/

1 голос
/ 04 января 2012

Я могу говорить только о Spring здесь.

Когда я был вынужден использовать Spring для не-REST проекта в прошлом году, я съежился.У меня было не только несколько дней, чтобы освоить основы, мне не нравилось все «волшебство», которое я делал, и я не был знаком с принципами IoC.

Но это выросло на мне.Это росло на мне довольно быстро тоже.С тех пор я использовал Spring для всех видов веб-проектов, включая тот, который предоставляет RESTful API.

Сильные стороны Spring, с моей точки зрения, заключаются в следующем: a) на самом деле он довольно легкий и обычно не учитывает вашиПосле того, как вы все настроите, б) множество примеров и отличное сообщество для поддержки, в) выполнение REST - это просто, как только вы правильно настроите конфигурацию, г) дизайн API, который заставляет богов плакать от радости, иe) IoC меняет жизнь.

Говоря о вашей озабоченности по поводу раздувания ... Я использовал другие веб-фреймворки для Java, и Spring - наименее распространенный из всех IMO.Это может выглядеть как много, но это действительно не так.По сравнению со Struts и Seam (о которых мне до сих пор снятся кошмары), Spring противоположен раздутию.Более того, IoC позволит вам уйти без необходимости писать тонны шаблонного шаблона, что сделает ваше приложение менее вздутым.

Вы упоминаете, что не хотите увязать в фреймворке по мере роста вашего приложения.Весной этого не произойдет, я вам гарантирую.Он предназначен для того, чтобы не мешать вам и удерживать вас от зависимости от какой-либо одной структуры.Ваш код - если он спроектирован правильно - в будущем может бросить Spring на что-то другое, не так уж много ругательств и ударов головой.Это одобряет соглашение по конфигурации, означая, что общие вещи должны работать из коробки без необходимости возиться слишком много.Для тех вещей, которые находятся вне стены, это дает вам достаточно веревки, чтобы повеситься.

Подводя итог, я бы высоко оценил Весну.

0 голосов
/ 04 января 2012

Я могу порекомендовать RESTlet 2.x , который я использую в каждом проекте.И RESTEasy , который я собираюсь использовать в будущем проекте.

Что мне нравится в RESTlet, так это все маршрутизация в одном месте.Он очень многофункциональный .

Что мне не нравится в RESTEasy, и я не слишком глубоко на это смотрю, это то, что в аннотациях все маршруты разбросаны по базе кодана каждый метод, из чего может быть много классов.Отсутствие их всех в одном месте усложнит обслуживание.

Почему я все еще рассматриваю RESTEasy, поскольку наличие нескольких GET методов для каждого класса может сократить взрыв класса resource, который может произойти вRESTlet.

Оба являются JAX-RS-совместимыми, если это важно, и любой из них требует значительных затрат времени и функциональности.

Что касается шаблонов, используйте StringTemplate держитесь подальше от таких вещей, как FreeMarker, они просто ведут к боли в обслуживании.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...