Существуют ли какие-либо недостатки для SEAM?

Question

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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 elsewhere (обратите внимание, что это не критика Seam - скорее JSF1.x и многие из них решаются в JSF2.0)

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

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

Answer 4

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

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

Answer 5

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

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

• модульного тестирования: получение SeamTest работать должным образом, особенно в непрерывной интеграции сборки было трудно, искать в Интернете «SeamTest вопросов». Также см. Это: Has anyone successfully run integration tests with Jboss embedded, Seam and Maven?
• Множество способов для разработчиков сделать что-то и не слишком много передовых методов документировано. Поэтому вам нужно потратить время и выяснить, что лучше для вашей проектной команды.Например, при реализации формы, вот потенциальные теги (обратите внимание, что некоторые из них пересекаются):

Facelets < УИ: повторить >

JSTL < C: Foreach >

JSF < ч : форма >

< ICEfaces лед: selectOneMenu >

JSF < F: selectitems >

Seam < s: кнопка >

• производительности подозреваемая, особенно с ICEfaces, here is a related article Кроме того, вам нужно "уровень гуру" знание пластов, чтобы сделать правильный выбор Вещь, по умолчанию у вас проблемы. Подробную информацию см. В этой статье: Speed up your Data-Driven JSF/Seam Application by Two Orders of Magnitude - Part 1
• , так как Seam 3 неизбежен и должен использовать 2 новые спецификации (JSF 2 и WebBeans), которые оставляют вопросы о том, что происходит с проектами на Seam 2 и как долго это займет вещи для получения стабильной
• обучения кривой. IMHO-шов пытается сделать слишком много, дает вам обертки над такими вещами, как iText, Quartz, JExcel, jBPM и т. Д. И интеграция Seam с сторонними платформами, как ожидается, станет шагом позади последних версий. Например, нам нужно было интегрировать jBPM напрямую, потому что нам нужны были некоторые из последних функций.
• Возможно, из-за отсутствия критериев запросов в JPA 1.X, как вы реализуете экраны динамического поиска (где пользователь заполняет множество опций фильтра и вы должны генерировать динамический HQL), чувствовал себя очень элегантно, и это при использовании рекомендуемого класса EntityQuery «Seam Application Framework» см. приведенную ниже ссылку для простого примера, но вы можете получить представление о том, что ожидать от сложных критериев фильтра, обрабатывая нули, порядок и все: How can I to order an EntityQuery query in a seam app?

Answer 6

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

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

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

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

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

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

Answer 7

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

Answer 8

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