Ответ 1
Мое понимание после работы один год в проекте GWT/Seam. Я предполагаю, что нет существующего веб-сайта, означающего, что вы можете начать с нуля. Если есть один, я предлагаю вам почтить свое наследие и улучшить его, выборочно вставляя виджеты GWT в определенные места существующих html-страниц (некоторые подробности здесь).
Наш процесс разработки можно приблизительно свести к следующему этапу (контуры обратной связи, встречи с закрытием и такие пропущенные, вы знаете сделку):
-
Запрос функции: содержит описание требуемой функциональности на высоком уровне
-
Проводные рамки: пользовательский интерфейс высокого уровня, который дает первое впечатление о том, как функциональность будет предоставляться конечному пользователю и как она интегрирована в существующее приложение (без каких-либо звонков и свистов)
-
Final Design: окончательный расширенный интерфейс новой функции, созданной нашим дизайнером (только для фотошоп, без 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 цента:)