Мои идеи после одного года работы над проектом GWT / Seam.Я предполагаю, что нет никакого существующего веб-сайта, означающего, что Вы можете начать с нуля.Если есть, я предлагаю вам почтить ваше наследие и улучшить его, выборочно вставляя виджеты GWT в определенные места существующих html-страниц (некоторые подробности здесь ).
Наш процесс разработкиможно приблизительно суммировать с помощью следующих шагов (циклы обратной связи, встречи в режиме ожидания и пр., вы знаете, что сделка):
Запрос функции: содержит описание требуемой функциональности на высоком уровне
Wire Frames: пользовательский интерфейс высокого уровня, который дает первое представление о том, как функциональность будет предоставлена конечному пользователю и как она интегрирована в существующее приложение (без каких-либо звонков).и свистит)
Окончательный дизайн: окончательный расширенный пользовательский интерфейс новой функции, созданной нашим дизайнером (только в фотошопе, без HTML-скелета, без CSS)
Внедрение и тестирование: я сосредоточусь на реализации и опишу, как она изменилась за один год
Мы началипроект с GWT 1.6, в котором отсутствует поддержка UiBinder .Поэтому было принято решение: 1) собрать всю клиентскую часть нашего приложения с помощью GWT (т. Е. Java-кода) или 2) построить наши страницы с помощью JSF (поскольку мы используем Seam) и расширить их с помощью виджетов GWT.Мы решили пойти по второму варианту главным образом потому, что нам понравилась идея передать большую часть состояния клиентам и позволить им выполнять обработку.И делать все в java было многообещающе с нашим большим опытом в разработке java.
Реализация бизнес-логики не была проблемой вообще.Больше всего времени у нас заняло создание пользовательского интерфейса: составление макета страниц и их оформление в java отнимает много времени и подвержено ошибкам.Разрыв между конечным html (на основе дизайнов из шага 3) и виджетами GWT был слишком велик.
Переход на UiBinder был первым шагом, который мы сделали, когда была выпущена версия GWT 2.0.Так как нам все равно пришлось переделывать большую часть нашего клиентского кода, мы также адаптировали шаблон MVP .После этого значительно возросла производительность: один разработчик внедрял бизнес-логику (в основном, часть представления MVP), в то время как другой занимался созданием части представления (.ui.xml и виджета). Модульное тестирование также стало более простым, потому что основные функции теперь были хорошо разделены в части докладчика (а GWTTestCase был частью прошлого).
Следующий важный шаг, который мы сейчас делаем, этоперейти от собственной реализации MVP к более сложной (а именно gwt-platform ).Обоснование этого решения: DI через GIN (зависимости ясны, а код становится чище), хорошая поддержка истории браузера (мы безрассудно пренебрегли ею - огромная ошибка!), Поддержка разделения кода, шаблон команд для асинхронных вызовов и некоторые другие.
Мой вывод после одного года опыта: используйте UiBinder для пользовательского интерфейса и переходите к чистой архитектуре MVP.Кривая обучения может быть крутой, но идти по тому же пути, что и у многих разработчиков GWT, у вас определенно больше времени.
... мои 2 цента:)