Причины НЕ использовать JSF [закрыто]

64

Я новичок в StackExchange, но я подумал, что вы сможете мне помочь.

Мы создаем новое приложение Java Enterprise, заменяющее устаревшее решение JSP. Из-за множества изменений пользовательский интерфейс и части бизнес-логики будут полностью переосмыслены и реализованы.

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

Прежде всего, он создает худшее, наиболее загроможденное недопустимое сочетание псевдо-HTML / CSS / JS, которое я когда-либо видел. Это нарушает все правила, которые я выучил в веб-разработке. Кроме того, он объединяет то, что никогда не должно быть так тесно связано: макет, дизайн, логика и связь с сервером. Я не понимаю, как мне было бы удобно расширять этот вывод, будь то стилизация с помощью CSS, добавление конфет пользовательского интерфейса (например, настраиваемые горячие клавиши, виджеты с перетаскиванием и т. Д.) Или что-то еще.

Во-вторых, это слишком сложно. Его сложность является выдающейся. Если вы спросите меня, это плохая абстракция основных веб-технологий, в конце концов искалеченных и бесполезных. Какие преимущества у меня есть? Нет, если подумать. Сотни компонентов? Кроме того, я вижу десятки тысяч фрагментов HTML / CSS, десять тысяч фрагментов JavaScript и тысячи плагинов jQuery. Это решает действительно много проблем - у нас не было бы, если бы мы не использовали JSF. Или шаблон фронт-контроллера вообще.

И, наконец, я думаю, что нам придется начинать сначала, скажем, через 2 года. Я не понимаю, как я могу реализовать весь наш первый макет GUI (кроме того, в нашей команде нет эксперта JSF). Может быть, мы могли бы как-нибудь взломать это вместе. И тогда будет больше. Я уверен, что мы можем взломать наш взломать. Но в какой-то момент мы застрянем. Из-за всего вышеперечисленного уровень обслуживания находится под контролем JSF. И нам придется начать все сначала.

Мое предложение было бы реализовать API REST, используя JAX-RS. Затем создайте клиент HTML5 / Javascript с клиентской стороной MVC. (или какой-то вкус MVC ..) Кстати; В любом случае нам понадобится API REST, так как мы также разрабатываем частичную оболочку Android.

Я сомневаюсь, что JSF является лучшим решением на сегодняшний день. Поскольку Интернет развивается, я действительно не понимаю, почему мы должны использовать эти «грабли».

Теперь, каковы плюсы / минусы? Как я могу подчеркнуть свою точку зрения не использовать JSF? Каковы сильные стороны, чтобы использовать JSF над моим предложением?

— Бруно Шеппер
источник

24

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

— ThiefMaster

2

Поскольку вы переписываете все, я не только рассмотрю вопрос об использовании JSF, но и вообще не буду использовать Java. Современные языки сценариев (т.е. не PHP или Perl) довольно приятны и удобны для разработчиков.

— ThiefMaster

11

Я не понизил голос, но это не вопрос, это напыщенная речь. Вэйн решил, что ненавидит JSF, теперь он просит больше причин не использовать его?

— Майкл Боргвардт

4

Java - лучший выбор, если ваше приложение будет большим (сложным и / или масштабируемым) и / или распределенным, используя множество сервисов; если ваше приложение не вписывается в эту категорию (не так сложно и не нуждается в масштабируемости), то Python (Django) или Ruby (Rails) будет лучшим выбором. Сложность JSF имеет преимущества, связанные с ее мощью; в качестве альтернативы вы должны взглянуть на другие веб-фреймворки, такие как Spring MVC или Struts 2, если Java является обязательным.

— m3th0dman

14

Это напыщенный поиск, а не вопрос как таковой.

26

Есть по крайней мере одна очень веская причина для рассмотрения JSF.

Это стандартная часть стека Java EE, и, следовательно, она будет доступна и будет работать во ВСЕХ контейнерах Java EE очень и очень долгое время. И поддерживается, без необходимости, если вы строго придерживались спецификации Java EE.

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

4

Я не уверен в этом. Для J2EE слова «стандартный» и «рабочий» не написаны на камне, особенно когда мы говорим о системе, которая будет / должна поддерживаться в течение многих лет, включая изменения в версии используемого j2ee.

— Магалланес

7

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

— Йенс Шаудер

@JensSchauder По моему опыту, вы можете писать переносимые приложения, переносить и обновлять их версии jsf. Это подразумевает знание спецификации и кодирование ее, а не ее реализацию. Это работает, как работает кодирование для JPA вместо Hibernate. Делал это годами.

— ymajoros

14

Теперь, каковы плюсы / минусы? Как я могу подчеркнуть свою точку зрения не использовать JSF? Каковы сильные стороны, чтобы использовать JSF над моим предложением?

Похоже, вы уже определились с минусами, и с некоторыми из них я согласен (это недостаточно разделяет компоновку и логику, а получающийся HTML часто отвратителен), но не согласен с другими (если вы используете Facelets, которые я бы очень рекомендовал, тогда вывод обязательно должен быть действительным).

Итак, вот некоторые плюсы:

Есть несколько очень мощных библиотек компонентов, таких как PrimceFaces или RichFaces, которые предлагают множество функциональных возможностей из коробки. Это может сэкономить вам много работы, если они покрывают ваши требования (не так много, если у вас есть необоротные требования, не покрытые ими).
Композитные компоненты предлагают очень чистый способ модульности ваших страниц
JSF очень хорошо интегрируется с остальной частью Java EE
AJAX с помощью рендеринга компонентов - это действительно просто и удобно

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

— Майкл Боргвардт
источник

1

Это не идентификаторы, это недействительные атрибуты. Например, "роль" и "расширенная ария" в представлении вкладок. Вы знаете, как это исправить?

— Бруно Шеппер

1

@ Vain: нет, похоже, другая проблема, возможно, с компонентом, который я не использовал или который является новым. Можно изменить вывод HTML компонентов JSF, указав альтернативный рендерер (который в идеале просто переопределяет один или два метода рендерера по умолчанию), но, конечно, это не то, что вам нужно делать, чтобы получить правильную разметку.

— Майкл Боргвардт

1

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

1

@ Thorbjørn Ravn Andersen Да, проблема с некорректным HTML на самом деле является проблемой PrimeFaces. Мы используем его, потому что он построен на jQuery-UI. Каков твой совет; я должен использовать другую библиотеку? Мне действительно нравится действительный HTML. Для меня это просто ОБЯЗАТЕЛЬНО.

— Бруно Шеппер

1

Возвращаясь к моему первому вопросу здесь, я хотел бы поделиться некоторым опытом о ваших плюсах: мы работаем с JSF, и с этим опытом мы бы не выбрали его снова. Едва ли что-нибудь работает, как ожидалось и из коробки. Да, есть мощные библиотеки. Но мы закончили тем, что делали все наши компоненты сами, потому что они не будут работать так, как нам нужно. Поразительно, как быстро у нас была своя собственная таблица данных с отложенной загрузкой при прокрутке. Композитные компоненты не работают для нас, я не могу сказать вам почему, они глючат, я думаю. Повторный рендеринг AJAX на самом деле является проблемой для JS на стороне клиента.

— Бруно Шэппер

9

JSF - это адекватный веб-фрейм с поддержкой состояния для Java, который является стандартом, что означает, что он поддерживается "из коробки" многими крупными поставщиками (включая FOSS). Он имеет сильную поддержку сторонних библиотек (PrimeFaces, IceFaces и т. Д.). Тем не менее, он в сущности «ломает сеть» из-за своего состояния (и многих других вещей). Посмотрите сравнение Мэттом Рэйблом веб-фреймворков на основе JVM , JSF обычно приближается к последнему.

Редактирование - с помощью JSF 2.2 - вы можете начать утверждать, что он не разрушает сеть так сильно, как когда-то. На самом деле интеграция с HTML5 не так уж и страшна :-).

— Мартейн Вербург
источник

1

Это действительно «разбивает сеть». И спасибо за сравнение Мэтта Рэйбла, я этого не знал.

— Бруно Шеппер

3

Обратите внимание, что JSF не обязательно с состоянием. Я согласен, что часто так и есть, но есть довольно хорошая поддержка запросов без сохранения состояния, основанных на GET, и если вы не используете форму, то состояния вообще нет.

— Арджан Тиймс

Честно говоря, Арджан, наверное, я только что видел много состояний.

— Мартейн Вербург

Ссылка на презентацию Raible

— zaidaus

6

У нас было устаревшее приложение JSP / Struts 1.0. Мы пропустили Struts 2, JSF и все остальное, что произошло после Struts 1, и перешли к Spring 3.0. Он имеет поддержку (и активное сообщество) для нашего списка пожеланий - Eclipse IDE, MVC и REST. Плюс мы отказались от нашего винтажного доморощенного Javascript / ajax для jquery.

YMMV, но весна была для нас гладкой миграцией.

— JQA
источник