MVP с точки зрения UI и View

Question

Что означает следующее?

ЦЕЛИ в GWT Develeopment

Нам нужны тупые просмотры, а не тупые пользовательские интерфейсы (Что означает здесь представление и что такое пользовательский интерфейс в MVP? Это сбивает с толку, пожалуйста, объяснитес небольшим, простым примером)

• Избегайте состояний в представлениях (о каком состоянии идет речь, объясните, пожалуйста, небольшим примером, простым)

• Поменяйте местами представления дляразные платформы (что такое подмена? подразумевает ли он изменение различных технологий, скажем, от GWT к Flex)

Объясните, пожалуйста, на простом примере:)

Спасибо

Answer 1

1. Что ж, я предполагаю, что это означает, что вам следует избегать наличия сложной бизнес-логики и состояний модели в ваших представлениях.Причина, по которой люди рекомендуют сохранять представления в GWT настолько тупыми, насколько это возможно, заключается в том, что представления имеют код, связанный с виджетами, и всякий раз, когда вы пытаетесь протестировать код, связанный с виджетами, в GWT, вам приходится возвращаться к медленному GWTTestCase, а не к быстрому * 1004.* tests.
   В TDD (Test Driven Development) вы в значительной степени полагаетесь на тесты, и для обеспечения эффективной разработки эти тесты должны выполняться быстро.
   Итак, что вы пытаетесь сделать в GWT, это сохранять представления как немыенасколько это возможно, чтобы они не требовали большого количества тестов (возможно, только интеграционных тестов в конце) и помещали весь связанный с бизнесом код в ваши докладчики.В Presenter не должно быть кода, связанного с виджетами, и он должен обрабатывать состояния модели.Затем вы можете использовать быстрые тесты JUnit, чтобы полностью охватить ваш код бизнес-логики в Presenters.См. здесь и здесь для получения более подробной информации.

2. Замена представлений для разных платформ относится, например, к различным реализациям представлений для разных устройств.Имеет смысл иметь разные макеты для почтового приложения при просмотре с разных устройств.
   На планшете с достаточным размером экрана у вас может быть список писем с левой стороны и фактический почтовый контент в центральной части.Однако на телефоне вы, вероятно, будете отображать только почтовый список, и при нажатии на почту представление будет изменено на содержимое письма.
   Бизнес-логика почтового приложения не зависит от макета / представления.Таким образом, вы пытаетесь поместить этот код в Presenter и спроектировать свои представления так, чтобы их можно было легко заменить, например, на основе пользовательского агента.Вы можете ознакомиться с примером приложения mobilewebapp в репозитории GWT и с этой конференцией ввода / вывода .

Answer 2

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

1. В MVP есть только одна концепция V. Избегайте V и UI в MVP, это одна и та же концепция. (UiBinder не имеет ничего общего с MVP, но вы можете использовать UiBinder для создания своего V для виджета MVP).
2. Модель является вашими данными и должна быть изменена только внутри вашего P.
3. V - это экран этих данных и никогда не должен его менять.
4. P обрабатывает данные, поведение вашего виджета, события для других виджетов и сервисов (RPC, Rest ...).
5. Избегайте хранить экземпляры ваших данных в вашем V.
6. V и P связываются друг с другом с обработчиками. Есть два способа сделать это. A) Обработка событий View непосредственно на P (пусть V реализует интерфейс, определенный в P) или B) , передавая ссылку P на View. Пусть P и V реализуют интерфейсы как контракт. Я рекомендую A .
7. Некоторые данные генерируются в V (TextArea, Combos ...) и в конечном итоге становятся частью вашей модели. Просто попытайтесь сохранить их изменения в P (как объяснено в 6).
8. P1 и P2 и P3 и ... связываются друг с другом через EventBus.
9. Пусть ваш P реализует IsWidget, это позволит вам создать экземпляр виджета MVP в V. другого виджета (вложенные виджеты). Это также позволит вам разбить большой MVP на несколько виджетов MVP (легко поддерживать, легко отслеживать с разными разработчиками ...).
10. Делая 6A), JAVA легко тестирует поведение вашего виджета (ваш P), только издеваясь над видом.
11. Проверьте свой V с селеном или другими.
12. Делая 6A), различные V могут реализовать внутренний интерфейс P. Один для мобильного, другой для ПК ... Это легче сказать, чем сделать.

Это все, надеюсь, это поможет вам.