Есть несколько вещей, о которых вы должны подумать при использовании этого подхода:
- Ваши специфические потребности против фокуса
конкретного каркаса
- Наличие кодеров, которые знают
рамки (внутренние и на
рынок)
- Кривая обучения для
Framework, а также уровень его принятия и поддержки в более широком сообществе разработчиков.
Многие люди высоко оценивают Spring MVC, хотя, если IOC для вас новичок (или вы не покупаете концепцию), это может быть немного больше, чем вы хотите откусить «все сразу».
Еще одна надежная опция - это Struts (хотя я настоятельно рекомендую Struts 2 для новой разработки).
С одной стороны, следует с осторожностью относиться к размеру и объему операции «трансплантации каркаса». Если ваше приложение остро нуждается в серьезной структурной реорганизации, вполне вероятно, что в конечном итоге вы могли бы начать с нуля и повесить куски существующей бизнес-логики на скелет, построенный на платформе. Время / деньги / ресурсы (и альтернативные издержки!) Не следует недооценивать, и вы должны быть уверены, что руководство действительно выкупает, чтобы вам не напали на вас на полпути. Здесь действительно очень важно «измерить трижды и сократить один раз» и убедиться, что вы откусываете кусок работы, которую вы можете прожевать - переходя от «устаревшего приложения» к «совершенно новому современному приложению с использованием всех новых технологий» "откровенно лучше всего делать поэтапно, а не все сразу.
Было бы полезно понять размер и относительную сложность приложения, а также его базовую природу (это приложение с очень интенсивным веб-интерфейсом или система бэк-офиса, которая выполняет много задач?), Чтобы сделать лучшие предложения по конкретным фреймворкам: хотя вы, безусловно, могли бы построить большинство веб-приложений на любой конкретной фреймворке, некоторые из них наклонены в большей степени в одном направлении, чем в другом (например, Struts и Wicket имеют довольно разную направленность)
Кроме того, нет ничего плохого в том, чтобы попробовать пару платформ-кандидатов вместе с существующим приложением. Хотя я ничего не знаю о технологической объединительной панели вашего текущего приложения, если вы не сделали что-то действительно странное, вполне возможно установить одну или несколько платформ и поэкспериментировать с ними вместе с вашим существующим приложением (например, написать новые функции против них или переписать части используя существующий код, затем подключите этот код к бэкэнду). Это позволит вам поэкспериментировать и «попробовать, прежде чем купить». Я бы посоветовал вашей команде обратить внимание на одного или нескольких кандидатов из «короткого списка», чтобы понять, как это будет работать на практике. Это, кстати, не самый страшный способ приблизиться к рефакторингу: постепенно заменяйте старые функциональные возможности своей новой платформой.
Последний (я думаю) совет: долго и пристально смотреть на свою модель данных и интерфейсы к ней. Как правило, именно в этом и заключаются настоящие гремлины, и независимо от структуры, которую вы хотите получить правильно. Я бы настоятельно рекомендовал сделать это вашей целью рефакторинга # 1, а не принятием конкретной структуры. Сильная модель данных сделает внедрение ЛЮБОЙ структуры (и обработку обновлений) намного проще ... и если ваше руководство изменит на вас указания и в конечном итоге отменит обновление структуры по какой-либо причине, то время, потраченное на рефакторинг модели данных, окупится.
EDIT:
Учитывая ваши комментарии о форме продукта, я бы удвоил совет "быть очень, очень осторожным". Место, в котором вы сейчас находитесь, очень распространено (и печально известно) и съело много команд (и карьер) живьем. Вы нуждаетесь в глубоком понимании и поддержке со стороны заинтересованных сторон в цепочке и со стороны бизнеса, поскольку это будет грандиозное мероприятие, которое по своей природе займет больше времени и будет стоить дороже, чем вы себе представляете. Способность технической команды быть ясными и реалистичными в отношении стоимости и масштабов изменений здесь имеет решающее значение для успеха - если вы значительно недооцениваете, вы подвергаете риску бюджет, карьеру и, возможно, сам бизнес. Если вы переоцените, вы, возможно, никогда не начнете:)
Один из подходов, когда у вас есть сильная заинтересованность и поддержка со стороны руководства, заключается в том, чтобы действительно относиться к этому как к целому новому продукту - перевести старые вещи на техническое обслуживание, закатать рукава и приступить к разработке системы замены со всеми знания, которые вы получили в предыдущей реализации. В этом случае я бы разработал sans-framework взаимодействия компонентов и данных, а затем посмотрю, как данный набор подходящих фреймворков будет поддерживать эту реализацию. Начало работы с каркасом может привести вас к неестественным местам и привести к тому, что вы окажетесь в том же месте в будущем.
Некоторые известные популярные фреймворки для проверки:
Struts2 - поддержка MVC / w AJAX
Калитка - AJAX Heavy
Struts1 - дедушка практически всех фреймворков Java; стоит посмотреть
Spring MVC - веб-структура Spring IOC