Доступные компоненты JSF MVC

Question

Я новичок в веб-программировании на основе Java и пытаюсь изучить JSF с нуля.Я слышал, что JSF объясняется как полное решение MVC, а Facelets - это чистая технология XML, включающая компонент «View» архитектуры MVC.

Итак, не зная никаких улучшений, я могу спросить: чтоварианты / альтернативы существуют для каждого компонента?Для каждого из 3 (Модель, Вид и Контроллер), какие существуют инструменты / API / библиотеки / технологии, которые будут работать с JSF.Например, если вы правильно понимаете основы View, JSP является (устаревшей / устаревшей) альтернативой Facelets.Любые другие?А как насчет компонента Модель: какие у меня есть варианты?Контроллер?

Опять же, сейчас просто интересно держать все под зонтиком JSF: если компонент совместим как часть решения JSF, я хочу услышать об этом!

Спасибо за любые рекомендации!

Answer 1

Я удивлен, что BalusC еще не ответил на этот вопрос одним из своих отвратительно полных ответов. Я подозреваю, что он доберется до этого, и когда он это сделает, я проголосую за это, потому что это будет здорово, поэтому не принимайте мой ответ прямо сейчас. А пока вот несколько мыслей:

JSF предназначен для полного стека MVC с акцентом на VC. У вас есть JSP / Facelets правильно. Проще говоря, не используйте JSP. Используйте Facelets. Они являются технологией представления по умолчанию для JSF 2. Они основаны на xml и не дадут вам повредить «интересным» взаимодействиям между жизненным циклом JSF и жизненным циклом JSP.

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

Что касается модели ... ну, любой хороший MVC-фреймворк оставит модель себе. Модель не должна знать или заботиться о том, в каком представлении она находится. Надеемся, что вы можете взять модель и отобразить ее на веб-странице, используя что угодно, от JSF до Wicket и Vaadin, а затем использовать ее в настольном приложении или на основе RESTful JSON. апи.

Вот несколько ссылок, по которым я бы предложил вам ознакомиться с JSF

.

• http://www.ibm.com/developerworks/library/j-jsf1/ (старше, но освоит основы)
• http://www.ibm.com/developerworks/library/j-jsf2/ (часть 2 выше)
• http://www.ibm.com/developerworks/library/j-jsf3/ (часть 3 выше)
• http://www.coreservlets.com/JSF-Tutorial/jsf2/ (учебное пособие Марти Холла

Answer 2

Я думаю, что вы понимаете правильно.

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

JSF не очень навязчив, когда дело касается модели. В идеале, в вашей доменной модели не должно быть никаких следов, которые вы используете JSF (исключение состоит в том, что JSF предоставляет аннотации, которые вы можете по желанию использовать, например, @ManagedBean). Это означает, что вы можете использовать любые библиотеки, которые захотите. Вы можете использовать Spring IOC или EJB, если хотите, или можете кодировать всю свою модель в виде простых старых объектов Java.

При этом я хотел бы подчеркнуть, что JSP не устарела. Как указывает digitaljoel, Facelets заменили JSP в качестве технологии просмотра в JSF, но JSP все еще жив и здоров в других средах. Не существует соглашения о том, что JSF, включая Facelets, «лучше», чем JSP (вместе с другим веб-фреймворком); и JSF не стал отраслевым стандартом.

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

Игнорирование характера запроса-ответа в Интернете увеличивает сложность запроса и вступает в противоречие с другой растущей тенденцией: многофункциональные веб-приложения, которые в значительной степени зависят от Javascript. Ответственность за логику представления переносится с сервера на браузер, который взаимодействует с сервером с помощью Ajax против тонких HTTP-API.

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