Избавляемся от шаблона GWT MVP

Следуя документации о местах и ​​мероприятиях + MVP, для каждой страницы мне нужно создать:

  • место
  • деятельность
  • токенизатор (я должен реализовать логику токенизации)
  • интерфейс для докладчика (действие реализует этот интерфейс)
  • интерфейс для представления
  • реализация представления
  • связыватель пользовательского интерфейса XML для реализации представления
  • узел в мапере активности приложения
  • узел в модуле джина для привязки интерфейса просмотра для просмотра реализации

Я создал приложение с основными функциями (5 страниц и панель навигации), и у меня уже есть более 1500 строк кода и ~40 файлов. Я думаю, что это абсолютно невозможно, однако я ничего не нашел по решению этой проблемы. Есть пара структур (например, GWTP), которые реализуют MVP, но им также нужно такое же количество шаблонов.

Я мог бы достичь той же функциональности в ~200 строк, используя Spring MVC или Play.

Что я делаю не так и как бы вы решили это?

Источник

2 ответа

Решение

Я думаю, что это абсолютно невозможно

Я не согласен с тобой. Большое количество маленьких файлов намного удобнее в обслуживании, чем пара больших файлов. Я согласен, что GWT гораздо более многословен, чем Spring MVC:

  • Вам не нужны все эти интерфейсы из-за динамической природы JSP
  • JSP в случае Sppring MVC не является строго типизированным и дает вам возможность автоматически делать много вещей низкого уровня (например, привязка данных).
  • И вообще ничего не делайте (нет необходимости очищать представление между запросами, представление не имеет состояния).

В случае GWT из-за строгой природы Java и представлений о состоянии вы должны сделать много дополнительной работы. Это полностью обслуживаемо (если все сделано правильно). Основным преимуществом является то, что вы можете добавить модульные тесты для уровня презентации. Из-за этого он будет более удобен для долгосрочных проектов со сложным пользовательским интерфейсом, большой базой кода и большой командой. Если это не так для вашего проекта (экраны просты, и вы не планируете добавлять модульные тесты для уровня пользовательского интерфейса), то может быть лучше:

  • использовать еще одну более легкую технологию представления (например, Spring MVC).
  • или упростить вашу политику (например, разрешить докладчику -> просматривать взаимодействия без интерфейсов). Обычно в этом случае вы теряете способность проводить модульное тестирование своих докладчиков. Как упомянул @Andrea Boscolo, вы можете использовать GwtMockito в качестве обходного пути для этой проблемы!

Два других преимущества интерфейсов между представлением и докладчиками:

  • Вы можете легко переключать реализацию представлений (известный пример создания desctop UI -> mobile UI switch, который, к сожалению, я никогда не видел реализованным)
  • Для меня это своего рода барьер, который помогает сохранить логику презентации в докладчике. Ведущий знает только о необходимых вещах. Мне нравится эта концепция. Это помогает мне писать все части в нужных местах.

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

  • Убедитесь, что вы используете шаблон UiBinder в Eclipse
  • Более того, вы можете написать свой генератор кода, который будет принимать имя активности и пакет в качестве параметров, а затем он сгенерирует все необходимые вещи. Так что вам нужно просто изменить ActivityMapper и начать писать важную логику пользовательского интерфейса. Это сделано для моего текущего проекта и делает меня счастливым.

Другим источником шаблонов является привязка данных. Рассмотрите возможность использования редактора

Источник

Основным преимуществом использования MVP с GWT является возможность модульного тестирования ваших презентаторов изолированно с использованием простого JUnit. TestCase вместо того, чтобы полагаться на мучительно медленно GwtTestCase,

Другие преимущества, такие как возможность поддержки, могут быть достигнуты с помощью более простых структур проекта, таких как @Maksym Demidas.

Таким образом, реальный вопрос заключается в том, хотите ли вы / нуждаетесь в такой степени тестирования внутри вашего проекта, за счет вышеупомянутого стандартного образца. Обратите внимание, что места и действия не имеют ничего общего с MVP: вы можете использовать их для достижения MVP, но они просто касаются навигации и просмотра переходов между местами (URL с).

Я бы действительно посоветовал вам взглянуть на недавнюю презентацию Эрика Куфлера в Google IO 2013 - Demystifying MVP and EventBus in GWT, Это должно помочь вам определить, когда использовать MVP, а когда нет. Кроме того, взгляните на библиотеку с открытым исходным кодом, которую он выпустил, специально для GwtMockito (т.е. тестирование логики виджета в простом JUnit TestCase).

Источник
Другие вопросы по тегам