Причини НЕ використовувати JSF [закрито]

64

Я новачок у StackExchange, але я подумав, що ти зможеш мені допомогти.

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

Першою нашою думкою був JSF, оскільки це стандарт у Java EE. Спочатку у мене було гарне враження. Але зараз я намагаюся реалізувати функціональний прототип, і є деякі по-справжньому серйозні проблеми щодо його використання.

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

По-друге, це занадто складно. Її складність видатна. Якщо ви запитаєте мене, це погана абстракція основних веб-технологій, каліка і марна врешті-решт. Які переваги у мене є? Ні, якщо задуматися. Сотні компонентів? Додатково я бачу десять тисяч фрагментів HTML / CSS, десять тисяч фрагментів JavaScript та тисячі плагінів jQuery. Це вирішує дійсно багато проблем - у нас не було б, якби ми не використовували JSF. Або взагалі шаблон переднього контролера.

І нарешті, я думаю, нам доведеться починати все, скажімо, через 2 роки. Я не бачу, як я можу реалізувати всі наші перші макети GUI (крім того, у нас в команді немає експерта JSF). Можливо, ми могли б якось їх зламати разом. І тоді буде більше. Я впевнений, що ми могли зламати наш хак. Але в якийсь момент ми застрягнемо. Завдяки всьому, що знаходиться вище, рівень обслуговування контролює JSF. І нам доведеться починати спочатку.

Моєю пропозицією було б реалізувати REST api, використовуючи JAX-RS. Потім створіть клієнт HTML5 / Javascript з MVC на стороні клієнта. (або якийсь аромат MVC ..) До речі; нам все одно знадобиться REST api, оскільки ми також розробляємо частковий фронтальний 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.

— magallanes

7

В моєму (обмеженому) досвіді з JSF цей аргумент насправді не відповідає. Я бачив, що програми застрягли в одній версії JSF, і немає розумного шляху міграції до нової версії. Впевнений, сервер додатків все-таки виконував його, але це було майже всією підтримкою, яку ви отримаєте, якщо у вас не буде великих грошей, щоб спалити за завищеними контрактами на підтримку.

— Єнс Шодер

@JensSchauder мій досвід полягає лише в тому, що ви можете писати портативні програми, мігрувати та модернізувати їх версію jsf. Це передбачає знати специфікацію та кодувати її, а не її реалізовувати. Це працює, оскільки кодування для JPA замість Hibernate працює. Робив це роками.

— ymajoros

14

Тепер, які плюси / мінуси? Як я можу наголосити на тому, що не використовувати JSF? Які сильні моменти використовувати JSF над моєю пропозицією?

Ви вже здаєтеся, що ви подумали про мінуси, і я повинен ознайомитись з деякими з них (це не відокремлює розкладку та логіку, і отриманий HTML часто є жорстоким), але не погоджуєтесь з іншими (якщо ви використовуєте Фасети, які я б дуже рекомендував, тоді висновок обов'язково повинен бути дійсним).

Ось ось деякі плюси:

Є кілька дуже потужних бібліотек компонентів, таких як 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 на стороні клієнта.

— Bruno Schäpper

9

JSF є адекватною потужною веб-базою для Java, яка є стандартом, що означає, що він підтримується поза коробкою багатьма основними постачальниками (включаючи FOSS). Він має потужну підтримку третьої сторони бібліотеки (PrimeFaces, IceFaces тощо). Однак він принципово «ламає мережу» завдяки своєму загальнонаціональному характеру (і купі інших речей). Див порівняння Метта Raible по базі 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
джерело