Современная веб-инфраструктура Java для приложений RESTful GUI?[закрыто]

StackOverflow https://stackoverflow.com/questions/2051851

Вопрос

Да, я знаю, старый вопрос о лучшем веб-фреймворке...но позвольте мне объяснить.

Я ищу веб-инфраструктуру на основе Java Servlet, которая обеспечивает взаимодействие RESTful, а также подходит для создания веб-интерфейсов.

Что я хочу:

  • Поддержка REST с согласованием содержимого HTTP и удобным сопоставлением URL-адресов.
  • преобразование данных из параметров запроса в объект домена (а в идеале и в другом направлении)
  • нет необходимости дублировать объект домена в качестве интерфейса для Интернета (как в Struts)
  • простая интеграция EJB
  • Внедрение зависимостей должно выполняться сервером Java EE.
  • понятный код (мне не нравится волшебное связывание компонентов Spring MVC в пути к классам)
  • легко настроить (то, что не настроено в Spring волшебным образом, утомительно настраивать в контейнере - иногда я предпочитаю прямые зависимости)
  • колесо не следует изобретать заново, т.е.г.что-то вроде JPA и BeanValidation должно использоваться, а не изобретаться заново в рамках платформы, или, по крайней мере, эти стандарты должны быть простыми в использовании.
  • Поддержка валидации с отображением ошибок в формах
  • поддержка интернационализации

Кандидаты:

  • Весенний MVC это мощный инструмент, но я устал от конфигурации Spring и мне не нравится модель программирования.Я думаю, что это слишком абстрактно и гибко и, следовательно, требует большой настройки.И мне не нравится, как Spring MVC использует аннотации.Но есть и некоторые недостатки дизайна, например, методы, которые возвращают значение через return и через выходной параметр - действительно ужасно!Я думаю, что было бы непросто использовать Spring MVC с внедрением зависимостей Java EE, поскольку Spring MVC в значительной степени зависит от Spring DI.

  • Ру Кажется, это круто, но это просто еще один способ создания приложения Spring MVC, и он делает некоторые странные вещи с AOP.

  • Стойки несколько неуклюжий и устаревший.

  • Полосы Подход ActionBean выглядит не намного лучше, чем Struts.Мне это не нравится.

  • Грааль хорошо, но глючно (по крайней мере до 1.2).Изобретает велосипед заново:Например, я бы предпочел JPA Горму.

Смотрите также 10 лучших веб-фреймворков Java

Я не ищу фреймворки с состоянием пользовательского интерфейса на сервере, такие как Wicket, Tapestry или JSF.Я считаю, что такой подход противоречит фундаментальным принципам Интернета!

Так что делать?Написать фреймворк с нуля?хм ...

Я хотел бы иметь что-то вроде JAX-RS с поддержкой классического графического интерфейса браузера.Например, платформа должна поддерживать проверку и помещать ошибку проверки в повторно отображаемую форму.Есть ли что-то подобное?Есть рекомендации?

Это было полезно?

Решение

Я думаю, что ваша характеристика Grails как «глючной» немного резка.Хотя при использовании Grails вы сталкиваетесь с ошибками, часто за это ответственны базовые платформы (Spring, Hibernate) или плагин, а не Grails.

Кроме того, учитывая, что Hibernate — это реализация JPA, имеет ли смысл говорить, что

Я бы предпочел JPA Горму

В любом случае, если вас действительно не устраивает Grails или любая другая упомянутая вами платформа, Игровая среда может стоит посмотреть.

Другие советы

Я писал в блоге об использовании JAX-RS в качестве объединение веб-фреймворка в прошлом.С помощью JAX-RS вы можете делать практически все, что вам нужно;Основным недостатком является то, что все части, возможно, не так хорошо документированы в одном месте, как в случае с такими вещами, как Spring MVC, Stripes, Grails, Seam и др.

Для представлений довольно легко использовать JAX-RS с Джерси и поддержка веб-интерфейсов в HTML в дополнение к сервисам RESTful в JSON/XML и т. д.Вы можете повторно использовать элегантное согласование содержимого JAXRS, чтобы заголовки принятия содержимого HTTP использовались для принятия решения о том, возвращается ли HTML или XML и т. д. (плюс вы можете взвешивать HTML на стороне сервера, чтобы избежать подачи XML некоторым веб-браузерам, которые предоставляют нечетные заголовки принятия - я смотрю на тебя Safari, который предпочитает XML HTML!).напримердобавление @ImplicitProduces("text/html;qs=5") в ваш ресурсный компонент придаст HTML больший вес, чем любое другое представление.Вы также можете настроить постфиксы URI (например, добавить .html, .xml или .json), чтобы переопределить согласование содержимого;что значительно упрощает тестирование различных представлений в браузере.

Джерси хорошо поддерживает неявные представления, поэтому вы можете отображать представления в HTML, используя любые шаблонизатор, такой как JSP или Шаблоны лифтов или что-то еще;затем используйте более традиционные поставщики JAX-RS для маршалинга типов XML/JSON.Вы можете либо явно выражать представления;или позвольте JAX-RS найти ваш шаблон и т. д.

Чтобы увидеть неявные представления в действии, вероятно, стоит загрузить исходный код для Джерси и просмотреть примеры, например, из книжного магазина (если хотите, найдите @ImplicitProduces).

Что касается таких вещей, как проверка, то легко интегрировать JSR проверки bean-компонентов в ресурсный компонент;поэтому вы можете выполнить пользовательскую проверку ресурса, DTO или чего-то еще.Точно так же в Джерси есть хорошая поддержка публикации форм (form beans).

Я бы рекомендовал использовать некоторую структуру DI/IoC для внедрения в ресурсные компоненты того, что им нужно (например, данных базы данных, данных проверки компонентов или объектов обслуживания или еще много чего).Guice очень хорошо работает с Джерси, если вы хотите избежать Spring;хотя Spring с JavaConfig избегает большого количества XML.

В наши дни для сложных пользовательских интерфейсов вы, вероятно, захотите использовать JavaScript на клиенте.Хотя из JavaScript легко вызывать restful-сервисы (особенно если они используют JSON или JSONP), недостающим элементом является элегантное повторное использование RESTful-сервисов в Java/JAX-RS из GWT.До сих пор РестиGWT выглядит наиболее многообещающе.Когда-нибудь, возможно, появится лучшая среда маршалинга JSON, Джексон будет иметь собственные привязки GWT.Идея заключалась бы в том, чтобы повторно использовать объекты DTO в GWT на стороне клиента и на стороне сервера JAX-RS, оставаясь при этом полностью RESTful.

Я хотел бы упомянуть Рестлет Фреймворк, которая была первой платформой REST для Java, выпущенной в 2005 году.Он зрелый, масштабируемый, имеет большую базу пользователей и активное сообщество.

Версия 2.0 находится на завершающей стадии разработки и предоставляет широкий набор функций, включая:

  • полное отображение концепций HTTP в чистом Java API
  • согласованный API для клиентской и серверной стороны
  • интеграция со многими популярными техносами (FreeMarker, Velocity, Spring, Jackson, XStream, JAXB, Atom, OData/WCF Data Services и т. д.)
  • может быть развернут в автономном Java SE, внутри контейнера Java EE/Servlet, в Google App Engine, Android и даже в GWT, для которого он знает, как автоматически сериализовать bean-компоненты с использованием отложенного связывания (аналогично GWT-RPC, но RESTful).
  • предоставляет множество соединителей для HTTP, SMTP, POP, JDBC, SIP и т. д.
  • встроенный полный пакет безопасности, ориентированный на веб-безопасность
  • поддержка JAX-RS как расширения
  • класс-ориентированный API, который предсказуем, легко расширяется и настраивается (в Java, XML, Spring, Groovy, Scala и т. д.) с поддержкой аннотаций Java, когда это действительно полезно.
  • и т. д.

Посмотрите проект и попробуйте:http://www.restlet.org/

Взгляни на Мастер DropWizard слишком ..

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

Кроме того, если вам нужна хорошая интеграция EJB, вы можете использовать resteasy с Фреймворк JBoss Seam

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top