Есть ли недостатки у SEAM?

Question

Как разработчик веб-приложений на Java, я использовал этот прошлогодний JSF (SUN) для каркаса своих веб-приложений. Должен сказать, мне очень понравилось его использовать, это облегчает разработку.

В последнее время я прочитал много хорошего о JBoss Seam, но я до сих пор не встречал человека, который использовал его. Из того, что я прочитал, кажется, что SEAM - это следующий шаг JSF.

Поэтому мой вопрос для вас, которые использовали SEAM: когда вы, работая с этой технологией, сталкивались с какими-либо недостатками? Вы сказали бы, что это естественно для вас?

Answer 1

Преимущество любого фреймворка, такого как SEAM или Grails, заключается в том, что это более высокий уровень абстракции. Он позаботится о ваших основных деталях и, если он хорошо спроектирован и написан, облегчит задачу.

Недостаток любого фреймворка, такого как SEAM или Grails, заключается в том, что он скрывает от вас много деталей. Если вы никогда не узнаете, что происходит, вы можете оказаться в мире проблем, если застряли и ничего не знаете о коде, который сгенерирован для вас.

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

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

Answer 2

Я использовал Seam в продолжающемся крупном проекте с IceFaces. Шов, конечно, намного лучше, чем использование простого JSF (см. Ссылку, размещенную Дамо на пару ответов выше).

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

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

Facelets

JSTL

JSF

ICEFaces

JSF

Шов

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

Answer 3

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

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

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

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

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

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

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

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

Answer 4

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

Answer 5

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

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

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

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

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

Будет ли вам полезен шов, зависит от того, с какими фреймворками вы собираетесь его использовать. Шов определенно имеет свою точку зрения, но это место растет. Шов определенно не мертвый проект. :)

Answer 6

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

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

Answer 7

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

Answer 8

Вы всегда можете использовать Factory annotation, чтобы избежать вызовов одного и того же метода снова и снова. Factory позволяет обновлять компонент.