Там какие-либо недостатки ко ШВУ?

Я использовал Seam в крупном проекте IceFaces. Seam, безусловно, намного лучше, чем использование простого JSF (см. Ссылку, опубликованную Damo несколькими ответами выше).

Однако некоторые из проблем, которые я помню:

• модульное тестирование: заставить SeamTest работать должным образом, особенно в непрерывном Сборка интеграции была сложной, поищите в Интернете «Проблемы с SeamTest». Также см. Это: Кто-нибудь успешно запускал интеграционные тесты со встроенным Jboss, Seam и Maven?
• Разработчики могут выполнять разные действия разными способами, но не так много задокументированных передовых практик. Поэтому вам нужно потратить время и выяснить, что лучше для вашей проектной команды. Например, при реализации форм вот возможные теги (обратите внимание, что некоторые из них перекрываются):

Facelets

JSTL

JSF

ICEFaces

JSF

Производительность Seam

• вызывает сомнения, особенно с IceFaces, здесь есть связанная статья Также , вам нужны знания Seam "на уровне гуру", чтобы делать то, что нужно, способ по умолчанию приводит вас к неприятностям. Подробности см. В этой статье: Ускорьте работу приложения JSF / Seam, управляемого данными, на два порядка - Часть 1
• , так как Seam 3 неизбежен, и предполагается, что в нем будут использоваться 2 новые спецификации (JSF 2 и WebBeans ), который оставляет вопросы о том, что происходит с проектами на шве 2 и сколько времени потребуется, чтобы все стало стабильно
• кривой обучения. IMHO seam пытается сделать слишком много, дает вам оболочки над такими вещами, как iText, Quartz, JExcel, jBPM и т. Д. И интеграция Seam со сторонними фреймворками, как ожидается, на шаг отстает от последних версий. Например, нам пришлось интегрировать jBPM напрямую, потому что нам нужны были некоторые из последних функций.
• может быть, из-за отсутствия критериальных запросов в JPA 1.X, как вы реализуете экраны динамического поиска (где пользователь заполняет множество фильтров параметры, и вам нужно сгенерировать динамический HQL) выглядело очень не элегантно, и это было при использовании рекомендованного класса EntityQuery "Seam Application Framework", см. ссылку ниже для простого примера, но вы можете получить представление о том, чего ожидать сложные критерии фильтрации, обработка нулей, упорядочение и все: Как я могу заказать запрос EntityQuery в приложении стыка?

Неверно говорить «Шов - это следующий шаг JSF». Seam не обязательно должен использовать JSF в качестве слоя представления. Он также может использовать Wicket или GWT .

Однако при использовании с JSF он значительно упрощает его. У вас меньше XML-конфигурации, чем у стандартного JSF, и я часто забываю, что JSF не имеет таких вещей, как контекст разговора или вызовы параметризованных методов в EL. например:

<h:commandButton action="#{myBean.sayHello('damo')}" value="hello"/>

С ним легко работать, и возможность использовать POJO везде очень раскрепощает. Его самые большие недостатки связаны с JSF:

• Слишком большая зависимость от HTTP POST (который s: кнопка / ссылка не всегда решает)
• Много javascript
• Чрезмерное количество обращений к геттерам / сеттерам
• Неприятный HTML; и т. д.

Более чем достаточно страниц с подробным описанием недостатков JSF в другом месте (обратите внимание, что это не критика Seam, а скорее JSF1.x, и многие из них устранены в JSF2.0)

Я не верю, что Seam - это «следующий шаг» для JSF, но он и Facelets имеют решающее значение, если вы планируете использовать JSF1.x прямо сейчас.

Я думаю, что следующим шагом будут JSF2.0 и WebBeans .

Seam, как среда интеграции, действительно покажет свою полезность в сочетании с другими платформами, которые вы хотите использовать.

Если вы собираетесь уже использовать EJB и JSF, SEAM - убийца.

Если вы собираетесь использовать JSF (плюс любые связанные с ним инструменты, такие как IceFaces или RichFaces), POJO SEAM могут значительно упростить вашу настройку, а также предоставить вам доступ к состояниям жизненного цикла, которые предоставляет seam (обсуждение и т. д.)

Если вы используете EJB с Wicket или GWT, Seam может также сохранить вам некоторую конфигурацию, хотя я лично не использовал его в этой конфигурации.

Как уже было сказано , Недостатки Seam присущи любой структуре абстракции: он скрывает от вас детали. Если он начнет протекать, у вас проблемы. Я' У меня еще не было утечек, но я также потратил время, чтобы дать себе хорошее, базовое понимание того, как это работает. Как EL работает с аннотациями швов и т. Д.

Собираетесь ли вы найти шов полезным, зависит от фреймворков, с которыми вы собираетесь его использовать. У Seam определенно есть своя золотая середина, но она растет. Шов определенно не мертвый проект. :)

Мне это кажется естественным, а использование аннотаций облегчает жизнь. Я даже не могу представить себе работу с фреймворком getAttribute / getParameter. Одним из недостатков является то, что seam-gen еще не работает с Maven (но Seam3 будет основан на Maven). Я думаю, что Seam заставляет вас сосредоточиться на том, чего вы хотите достичь, и с другими фреймворками вы должны думать, как это сделать. Вы когда-нибудь пробовали использовать Ajax с javascript / prototype / jquery? Это действительно больно по сравнению с шовной кнопкой Ajax с вызовом метода и тем, что перерендерить. Javascript вообще не нужен со швом и Rich Faces. для меня это лучший фреймворк, который я использовал.

Мне нравится JSF, и я недавно оценил Seam. JSF - это структура веб-интерфейса, тогда как Seam - это более общая среда веб-приложений, которая объединяет не только JSF, но и диалоговые контексты, рабочий процесс (jBPM) и постоянство объектов (предпочтительно EJB3). Сначала меня привлекли в Seam рекламируемые автоматически генерируемые леса, но я так и не смог заставить их работать с моей корпоративной моделью данных. С тех пор меня больше интересуют Spring Framework и Spring JSF. Мне он нравится как более модульный, и если вы используете iBATIS, ему нужен только контейнер сервлетов, такой как Tomcat, а не контейнер Java EE, такой как JBoss. Spring существует дольше и имеет больше внимания.

Также ICEfaces отлично работает с JSF и фейсклетами, он отлично работает с такими приложениями, как Seam или Spring, или без них.

Если вы поставите логгер на ваш компонент Seam (например, resultList), вы увидите, что Seam вызывает один и тот же метод много раз. Это единственное, что раздражает в Seam. Но Seam определенно "исправил" JSF, который сам по себе довольно запутанный. Давайте посмотрим на JSF2. Несмотря на эти проблемы, я очень рад использовать Seam.