Рекомендации JavaServer Faces (JSF), Struts, model2, другое

Есть несколько вещей, о которых вы должны подумать, применяя этот подход:

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

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

Другой хорошо зарекомендовавший себя вариант — Struts (хотя я бы настоятельно рекомендовал Struts 2 для новой разработки).

Одна вещь, которой следует опасаться, — это размер и масштаб операции по «трансплантации каркаса». Если ваше приложение остро нуждается в серьезной структурной реорганизации, вполне вероятно, что вы можете в конечном итоге начать с нуля и подвесить куски существующей бизнес-логики к скелету, построенному на основе фреймворка. Не следует недооценивать время/деньги/ресурсы (и альтернативные издержки!), и вы должны быть уверены, что руководство действительно откупится, чтобы вас не отключили на полпути. Здесь действительно очень важно «трижды отмерить и один раз отрезать» и убедиться, что вы откусываете кусок работы, который можете прожевать — переход от «устаревшего приложения» к «совершенно новому современному приложению, использующему все новые технологии». «Честно говоря, лучше всего делать поэтапно, а не все сразу.

Было бы полезно понять размер и относительную сложность приложения, а также его базовую природу (это приложение с очень интенсивным веб-интерфейсом или система бэк-офиса, которая выполняет много работы?), чтобы сделать лучшие предложения о конкретные фреймворки: хотя вы, безусловно, можете создавать большинство веб-приложений на любой заданной инфраструктуре, некоторые из них более сильно наклонены в одном направлении, чем в другом (например, Struts и Wicket имеют совершенно другую направленность)

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

Последний (я думаю) совет: долго и внимательно смотрите на свою модель данных и интерфейсы к ней. Обычно это место, где находятся настоящие гремлины, и независимо от того, какой фреймворк вы хотите сделать правильно. Я настоятельно рекомендую сделать это вашей целью рефакторинга № 1, а не принимать конкретный фреймворк. Сильная модель данных значительно упростит внедрение ЛЮБОЙ структуры (и обработку обновлений)... и если ваше руководство изменит ваши указания и в конечном итоге отложит обновление структуры по какой-либо причине, время, потраченное на рефакторинг модели данных, окупится.

ИЗМЕНИТЬ:

Учитывая ваши комментарии о форме продукта, я бы удвоил совет «будьте очень, очень осторожны». Ситуация, в которой вы сейчас находитесь, очень распространена (и печально известна) и съела заживо многие команды (и карьеры). Вам необходимо глубокое понимание и поддержка со стороны заинтересованных сторон в цепочке и со стороны бизнеса, поскольку это будет огромное мероприятие, которое по своей природе займет больше времени и будет стоить больше, чем вы себе представляете. Способность технической команды быть ясным и реалистичным в отношении стоимости + масштаба изменений здесь имеет РЕШАЮЩЕЕ значение для успеха - если вы значительно недооцениваете, вы ставите под угрозу бюджет, карьеру и, возможно, сам бизнес. Если вы переоцените, вы можете никогда не начать :)

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

Некоторые известные популярные фреймворки для проверки:

Struts2 — поддержка MVC/w AJAX

Wicket — тяжелый AJAX

Struts1 — дедушка почти всех фреймворков Java; стоит посмотреть

Spring MVC — веб-фреймворк Spring IOC

Если вам понравился JSF и вы хотите его использовать, я бы порекомендовал использовать JBoss Seam. Вы также можете использовать Spring, но я думаю, что использование JBoss Seam значительно упрощает использование JSF. Пользуюсь уже почти 1 год с хорошими результатами. И если вы хотите смоделировать свой процесс как бизнес-процесс, вы можете попробовать JBPM (вместе с Seam).

Если вы хотите узнать больше об гибких методологиях, чтобы вы могли улучшить как свои методологии, так и практики, сначала ознакомьтесь с манифестом agile http://agilemanifesto.org/ . А затем начните пробовать устоявшиеся методологии, такие как XP или Scrum.

Но не торопитесь, начните пробовать одно изменение вместо другого, чтобы не запутаться.

JSF позволяет вам сосредоточиться на компонентах, в то время как решения на основе JSP делают это не так хорошо или не так сильно. Вы по-прежнему обнаружите, что кодируете много JSP-форматов HTML, в то время как с решениями JSF вам это действительно не нужно. Посмотрите на RichFaces или IceFaces как на библиотеки. RichFaces упрощает работу с AJAX. Просто добавьте тег <a4j:support event="onkeyup" reRender="output"/> к стандартному элементу управления JSF. В приведенном выше примере при событии keyup для элемента управления будет повторно отображаться область <a4j:region или другой тег JSF, Richfaces. Ничего проще.