Использование JSF против других веб-фреймворков

Question

Мы находимся в процессе переоценки нашего использования JSF (введенного до того, как я пришел в проект) по сравнению с возможным использованием других веб-сред, таких как Spring MVC.

С моей точки зрения, кажется, что время разработки для создания страниц занимает очень много времени с использованием JSF (никогда не разрабатывалось с) по сравнению с использованием Spring MVC (с которым я знаком).

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

Интересно, если я не здесь, или, может быть, команда на месте не является той командой или имеет правильный набор навыков для работы с JSF.

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

Мы создаем сайт электронной коммерции / аукциона, работающий на WebSphere 6.1. Мы используем Spring и Hibernate.

Answer 1

Минусы JSF мы нашли:

• «Стандартный» 5-фазный путь очень прост и негибок.
• Отклонение от обычного метода является сложным и неинтуитивным
• Вы просто не можете использовать JSF без Facelets и Rich / ICEFaces ... по крайней мере, другие модификации / дополнения полезны (SEAM и т. Д.)
• Нормально инкапсулировать функциональность, чтобы сделать вещи "проще" ... НЕДОПУСТИМО, чтобы почти невозможно было прятаться там, когда этого требуют обстоятельства.
• Хранение на стороне сервера дерева компонентов невероятно неудобно при попытке создать реагирующую на стороне клиента страницу.

Мы переехали в Groovy / Grails здесь. Соглашение «по умолчанию» легко понять и легко обойти при необходимости. Соглашения также применяются к изменению структуры (без изменений файла multi-xml / code). Мне еще нужно изменить XML-файл вручную. С ним проще работать, и он достаточно гибок для того, что нам нужно.

Grails включает Spring WebFlow и Hibernate, только вам не нужно изменять XML; Соглашения о кодировании Grails преобразуются во время компиляции / выполнения.

Answer 2

Я тоже большой поклонник Spring MVC - особенно когда он используется в сочетании с Spring Webflow, что просто потрясающе. Теперь Webflow можно использовать с другими веб-фреймворками, но наиболее естественно он подходит для Spring MVC.

В моем случае я перешел из Struts (1) в Spring MVC. У нас было много застроенной инфраструктуры для использования Struts. Одна вещь, которую я недооценил при написании новых страниц в Spring MVC, это то, сколько времени мы потратили бы на переосмысление этой инфраструктуры. Я говорю о проверке, общей логике и т. Д.

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

Я считаю, что Spring MVC и Webflow лучше всего подходят, если у вас есть инфраструктура вокруг проверок и логики форм. Например, в нашей системе этот процесс часто выполнялся:

1. Пользователь размещает заказ;
2. Сервер проверяет параметры и либо отклоняет заказ (возврат к (1)), либо принимает его;
3. Подтвержденный заказ возвращается отображаемому пользователю, который подтверждает, что он хочет разместить заказ или отменить его;
4. Если они отменят его, отобразите страницу с сообщением об отмене;
5. Если они одобрят это, проверьте заказ еще раз;
6. Если проверка не пройдена, вернуться к (1);
7. В противном случае разместите заказ и отобразите результат для пользователя.

Возможно, это звучит запутанно, но очень много. Spring Spring MVC действительно подходит для такого рода сценариев, вы можете создать собственный контроллер, и тогда фактическая реализация просто становится проблемой подключения правильных представлений и поддержки bean-компонентов.

Не стоит недооценивать стоимость разработки и тестирования необходимой инфраструктуры.

Еще одна вещь, которую следует учитывать, это командный опыт: если никто другой не имеет опыта Spring MVC, то это вызовет некоторые проблемы.

Так что будьте очень осторожны, чтобы не измениться только потому, что это сделает вас лично более комфортным.