Существует ли какой-либо другой сильно интегрированный инструмент уровня представления, кроме JSF/JSP для Java EE?
-
08-07-2019 - |
Вопрос
Я преподаю Java EE в университете, и этот вопрос задал студент.Я сказал «нет», но не был до конца уверен, поэтому решил спросить вас, великие разработчики.:)
По сути, я бы хотел использовать сущности, если бы они были в моем контексте:кошачьи геттеры, сеттеры и т. д., как и обычные POJO.если я использую EJB, используя его удаленный интерфейс, объекты отделяются от базовой инфраструктуры, так что это бесполезно.
Я думал о том, чтобы написать такой слой в своей магистерской диссертации.Если это мертвая идея, не стесняйтесь сказать мне.Если нет, скажите мне, хотите ли вы его.
Или, если есть такой инструмент, дайте мне знать!
Решение
В простом современном мире приложений Java EE оно разбито на несколько уровней, где у вас есть 4 основных уровня
+--------------------+
| Presentation |
+--------------------+
| Controller/Actions |
+--------------------+
| Business Delegate |
| (Service) |
+--------------------+
| Data Access Layer |
+--------------------+
| Database |
+--------------------+
Ваши приложения должны быть разделены на эти слои с самого начала, так что вы можете в любой момент времени заменить любой слой, не затрагивая ни одного из его родственных слоев.
Например, если вы использовали JDBC для уровня доступа к данным, вы сможете заменить его на Hibernate, не затрагивая бизнес-делегат или уровень базы данных. Преимущество использования такой архитектуры заключается в возможности совместной работы с несколькими технологиями. Ваш бизнес-делегат (сервисный уровень) должен иметь возможность общаться с веб-сервисом и обрабатывать обработку приложения, даже не заходя в браузер!
Что касается использования JSP в качестве уровня представления, существуют другие технологии, такие как скорость , freemarker , как упомянул выше iberck, у гобелена также есть собственный механизм рендеринга. Вы можете использовать XML + XSLT также для визуализации пользовательского интерфейса. Также доступны приложения для управления пользовательским интерфейсом, такие как Tiles и sitemesh , которые помогают интегрировать различные технологии в разные компоненты страницы и отображать их как один.
Вы также можете использовать легкие качающиеся компоненты, заколоченные с помощью JNLP и разработать корпоративное приложение в стиле рабочего стола. Все, что нам нужно, это немного воображения и требования клиента, и мы можем использовать буквально все что угодно в качестве уровня представления. Р>
Другие советы
Ах.Кажется, вы не правильно поняли мой вопрос :)
Компоненты предназначены для предоставления услуг внутри приложения.Допустим, я хотел бы разработать автономное Java-приложение с графическим интерфейсом Swing, и из этого приложения я хотел бы использовать объекты, присутствующие в области приложения Java ee.
Вот что я хотел бы сделать без проблем:создавайте сущности, изменяйте их, удаляйте их интуитивно понятным способом, не заботясь о проблемах отсоединения EntityManager (если вы вызываете EJB удаленно и он передает обратно объект сущности, он будет отсоединен перед возвратом).
Я не хочу разрабатывать веб-приложение.JSF/JSP и подобные им тесно интегрированы, но во многих средах лучше использовать отдельное клиентское приложение.:)
Просматривая ваш комментарий посередине, я вижу, что вам нужна среда рабочего стола поверх Java EE.
Ответ здесь заключается в том, что JSF работает над сервлетом API. И это определенно для Интернета, но подождите, вы все равно можете вставить tomcat или jetty в свое приложение!
Возможности практически безграничны, если ваш бизнес-уровень четко определен, просто создайте колебательный уровень, который вызывает ваши бизнес-функции.
Кроме того, Java EE - это API, некоторые части можно заменить, или вы можете просто использовать его часть. Контейнер в основном предназначен для работы с EJB, сервлетами JNDI и другими мелочами. Все это также может быть использовано в настольных приложениях.
Таким образом, ответ зависит от вашей конкретной цели и фактического дизайна / реализации приложения.
Одной из альтернатив является Spring Framework . Spring предоставляет собственную поддержку привязки объектов-сущностей к представлению и обрабатывает получение / настройку для вас после его подключения. Есть много модулей Spring на выбор. Spring MVC и Spring Webflow стоит проверить. С Spring MVC (IMO) проще начать, но Sring Webflow допускает более сложную навигацию и больше возможностей области (например: область действия потока). Если вы ищете книгу, Spring In Action - спуск. Существуют некоторые концепции, которые вам необходимо решить (например, внедрение зависимостей), чтобы использовать Spring, но это того стоит.
Другой альтернативой является Tapestry5 . Tapestry - это инфраструктура с открытым исходным кодом для создания динамических, надежных и масштабируемых веб-приложений на Java. Tapestry дополняет и основывается на стандартном API сервлетов Java и работает в любом контейнере сервлетов или на сервере приложений.
Tapestry делит веб-приложение на набор страниц, каждая из которых состоит из компонентов. Это обеспечивает согласованную структуру, позволяя платформе Tapestry взять на себя ответственность за ключевые проблемы, такие как построение и отправка URL-адресов, постоянное хранение состояния на клиенте или на сервере, проверка ввода данных пользователем, локализация / интернационализация и создание отчетов об исключениях. Разработка приложений Tapestry включает в себя создание шаблонов HTML с использованием обычного HTML и комбинирование шаблонов с небольшим количеством кода Java. В Tapestry вы создаете свое приложение с точки зрения объектов, а также методов и свойств этих объектов, а конкретно - не с точки зрения URL-адресов и параметров запроса. Tapestry приносит истинно объектно-ориентированную разработку в веб-приложения Java.
Идеология, лежащая в основе bean-компонентов, в настоящее время находится в любой известной Java-среде. Как уже упоминалось, Spring - это хорошая / отличная универсальная среда бизнес-логики (ознакомьтесь с ее jdbc template классы, это просто потрясающе - еще одна замечательная жемчужина - это applicationContext.xml , которая есть), а для слоя представления я лично предпочитаю Apache Wicket .
Я не верю, что вы должны создавать свои собственные, но вместо этого найдите среду, которая соответствует вашим потребностям, и начните вносить свой вклад в ее кодовую базу, чтобы начать работу с уже сформированной пользовательской базой, и ваш код будет создаваться более тщательно. что, в свою очередь, сделает вас лучшим программистом.
grails ( http://www.grails.org/ ) или грифон ( http://griffon.codehaus.org/ ) может представлять интерес
StringTemplate написана Терренсом Парром, парнем из ANTLR. Если вы заинтересованы в создании какого-либо текстового представления из модели, это очень хорошо.
Я получил отличные результаты, используя его для создания XML, веб-страниц и точечных файлов из той же модели. Вы пишете шаблон для визуализации объекта. Этот шаблон может вызывать другие шаблоны (включая рекурсивные) на основе данных, полученных из модели. (qv Функции изображения )
Получатели и map.get ()
могут вызываться непосредственно из шаблонов. Модель может быть любой POJO. ST гордится своим строгим отделением от контроллера, поэтому в самих шаблонах допускается очень мало логики.
Как и во всех этих маленьких языках, это что-то новое для изучения, и может быть не тем, что вы ищете. Это было действительно хорошо для меня.