«Спокойный» Фреймворки Java WEB MVC

Приложение, которое я разрабатываю, будет" отзывчивым ", будет выполнять асинхронную связь и передавать много JSON туда и обратно.

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

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

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

3) Прямая поддержка обработки JSON . Использование произвольного процессора json по моему выбору, например, jackson или gson e.t.c ..

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

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

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

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

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

Spring MVC 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, построенный на процессоре Jackson JSON. Эта реализация включается автоматически при использовании mvc. : управляемый аннотацией элемент конфигурации с Джексоном, присутствующим в вашем пути к классам. "

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

4) Да

5) Да

6) Да

Play Framework

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

2) Ага, и это так элегантно. Пальцы вверх.

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

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

5) Ага. Использует заводной. Меня устраивает.

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

Restlet

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

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

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

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

4) Описывает себя как «агностик настойчивости». Хорошо, я думаю, это хорошо. Но я хочу упорствовать и не изобретать сантехнику самостоятельно. Или, по крайней мере, я хочу немного показать, как это МОЖЕТ быть сделано с некоторыми усилиями. Есть сторонний модуль jpa, но он построен на restlet 1.0.У Restlet есть пружинный модуль, так что, возможно, я смогу интегрироваться с материалом Spring Persistance ...

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

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

РЕЗЮМЕ

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

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

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

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