Приложение, которое я разрабатываю, будет «отзывчивым», будет поддерживать асинхронную связь и передавать много JSON туда и обратно.
Мне нужна веб-платформа Java MVC, поддерживающая
1) Минимальное количество BLOAT и "закулисная магия". В любом фреймворке всегда есть компромисс между функциональностью фреймворка и сложностью. Но когда приходит время, когда я сталкиваюсь с проблемой и мне приходится «бороться с рамками» (а это время всегда приходит), я хочу, чтобы это была честная борьба. Сведение к минимуму размера рамки увеличивает вероятность честного боя.
2) Встроенная поддержка RESTFUL. Т.е. маршрутизация html-глаголов и согласование содержимого.
3) Прямая поддержка обработки JSON. Использование произвольного процессора json по моему выбору, то есть jackson или gson и т. Д.
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. Не знаю, удобно ли мне развертывать конфиденциальные данные и полагаться на игру! рамки для безопасности. Наверное, придется что-то надстроить.
Рестлет
Возможно, это своеобразный кандидат, так как он предназначен для использования в «беспокойных веб-сервисах». Но для моих пунктов (1) - (6) и моего типа приложения, в котором большая часть взаимодействия с пользователем является асинхронным, это кажется подходящим вариантом. Я могу запускать его на статических ресурсах или динамически сгенерированном контенте и выдавать любой тип контента.
1) Restlet 1.1.1 составляет около 54 МБ. Посмотрел пример hello world. Мне понравилось отсутствие файлов XML. И так же, как и в игре, у него есть собственный сервер (коннекторы причалов). Пример hello world выглядел очень простым и понятным.
2) Да, и подход очень "программный"
3) Да, но кажется только через модуль расширения jackson. Учитывая программный характер этого фреймворка, вполне вероятно, что есть и другие варианты, но я ничего не нашел в документации или на форумах групп пользователей.
4) Называет себя «агностиком настойчивости». Хорошо, я думаю. Но я хочу упорствовать и не изобретать сантехнику самостоятельно. Или, по крайней мере, я хочу немного показать, как это МОЖЕТ быть сделано с некоторыми усилиями. Есть сторонний модуль jpa, но он построен на рестлете 1.0. У Restlet есть пружинный модуль, так что, возможно, я смогу интегрироваться с материалом Spring Persistance ...
5) Да, есть расширение freemarker
6) Имеет для этого родную схему. На первый взгляд, не такой «богатый», как пружинная безопасность. Опять же, может я смогу интегрироваться?
РЕЗЮМЕ
Spring MVC 3: поддерживает все требования, возможно, за исключением (1). Единственное, что меня беспокоит, так это то, что это кажется сложным, и у меня возникает смутное неприятное ощущение, что я не контролирую ситуацию. Я действительно не хочу «увязнуть» в фреймворке позже, когда мое приложение будет расти.
Игра: очень приятные впечатления. Даже весело. Если бы только схема безопасности была более продвинутой, или если бы я мог хотя бы интегрироваться с Spring Security (и найти документацию о том, как это сделать)
Рестлет: по какой-то причине мне понравился этот фреймворк. Программный подход вызывает чувство контроля. Но если я не могу проявить настойчивость каким-то легким способом, то это не годится. Не могу понять, почему это не встроено. Разве это не всем нужно?
- Что говорят люди, которые использовали любой из вышеперечисленных фреймворков?
- Мои наблюдения точны?
- Я упустил рамки, которые должны быть здесь?
- Альтернативы?
