Какова Ваша рекомендация для проектирования приложений GWT? MVC, MVP или пользовательское решение для обмена сообщениями?

Вот недавняя презентация Google IO по созданию архитектуры вашего GWT-приложения .

Наслаждайтесь.

-JP

Я рад, что этот вопрос был задан, потому что GWT отчаянно нуждается в рельсовом способе структурирования приложения. Простой подход, основанный на лучших практиках, который будет работать для 90% всех случаев использования и обеспечивает сверхлегкую тестируемость.

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

Мое решение заключалось в следующем: Ведущий обрабатывает эти события и уведомляет другие виджеты / представления и / или вызывает gwt-rpc, который в случае успеха помещает свой результат в модель. Модель имеет типичный механизм прослушивания изменения свойств "Property [List [String]] names = ....", который зарегистрирован ведущим, так что обновление модели по запросу gwt-rpc распространяется на все представления / виджеты, которые

С этой оценкой я получил очень легкую возможность тестирования с помощью EasyMock для моих AsynInterfaces. Я также получил возможность легко обмениваться реализацией представления / виджета, потому что все, что мне нужно было переписать, это код, который уведомлял ведущего о каком-то событии - независимо от базового виджета (кнопки, ссылок и т. Д.).

Проблемы с моим подходом:

• Моя текущая реализация затрудняет синхронизацию значений данных между центральными моделями разных экранов. Допустим, у вас есть экран, на котором отображается набор категорий, и другой экран, который позволяет вам добавлять / редактировать эти элементы. В настоящее время очень сложно распространять эти события изменения через границы экранов, потому что значения кэшируются в этих моделях, и трудно определить, являются ли некоторые вещи грязными (было бы легко в традиционном web1.0-html -dumb-terminal тип сценария с декларативным кешированием на стороне сервера).
• Параметры конструктора представлений обеспечивают сверхпростое тестирование, но без надежной инфраструктуры внедрения зависимостей внутри "onModuleLoad (") будет некрасивый заводской / установочный код. ) ". В то время, когда я начал это, я не знал о Google GIN, поэтому, когда я реорганизую свое приложение, я воспользуюсь этим, чтобы избавиться от этого шаблона. Интересный пример - игра «HigherLower» внутри GIN-Trunk.
• Я не правильно понял историю в первый раз, поэтому мне сложно переходить из одной части моего приложения в другую. Мой подход не учитывает Историю, что является серьезным спадом.

Мои решения этих проблем:

• Использование GIN для удаления шаблона установки, который трудно поддерживать
• При переходе от Gwt-Ext к GXT, использовать его инфраструктуру MVC в качестве EventBus для присоединения / отсоединения модульных экранов, чтобы избежать проблем с кэшированием / синхронизацией
• Подумайте о каком-то «Месте» -абстракции, как Рэй Райан описал в своем выступлении на I / O 09, который объединяет Разрыв между подходами GXT-MVC и GWTs-Hitory
• Использование MVP для виджетов для изоляции доступа к данным

Резюме:

Я не думаю, что можно использовать один подход «MVP» для всего приложения. Определенно нужна история для навигации по приложениям, шина событий, такая как GXT-MVC, для присоединения / отсоединения экранов, и MVP, чтобы обеспечить легкое тестирование доступа к данным для виджетов.

Поэтому я предлагаю многоуровневый подход, который объединяет эти три элемента, поскольку я считаю, что решение «one-event-mvp-system» не работает. Навигация / прикрепление к экрану / доступ к данным - это три отдельные задачи, и в следующие месяцы я проведу рефакторинг своего приложения (перейду на GXT), чтобы использовать все три фреймворка событий для каждой задачи отдельно (лучший инструмент для работы). Все три элемента могут не знать друг друга. Я знаю, что мое решение применимо только к проектам GXT.

При написании больших приложений GWT я чувствую, что должен заново изобретать что-то вроде Spring-MVC на клиенте, что действительно отстой, потому что это занимает много времени и умение выплевывать что-то элегантное, как Spring MVC.

Вам следует взглянуть на Портлеты GWT . Мы разработали GWT Portlets Framework во время работы над большим приложением HR Portal, и теперь оно бесплатное и с открытым исходным кодом. С веб-сайта GWT Portlets (размещенного в коде Google):

Модель программирования в некоторой степени похожа на написание портлетов JSR168 для сервера портала (Liferay, JBoss Portal и т. Д.). «Портал» - это ваше приложение, созданное с использованием инфраструктуры портлетов GWT в качестве библиотеки. Функциональные возможности приложения разработаны в виде слабо связанных портлетов, каждый из которых имеет дополнительный DataProvider на стороне сервера.

Каждый портлет знает, как передать свое состояние в сериализуемый подкласс PortletFactory (шаблон momento / DTO / factory), что делает возможными важные функции: небольшие кнопки инструментов и меню, управляемое шаблонами HTML

Портлеты GWT реализованы в коде Java и не содержат внешних библиотек Javascript. Он не требует какой-либо серверной инфраструктуры (например, Spring или J2EE), но разработан для хорошей работы в сочетании с такими структурами.

Если вы заинтересованы в использовании архитектуры MVP, вы можете взглянуть на GWTP: http://code.google.com/p/gwt-platform/ . Это MVP-фреймворк с открытым исходным кодом, над которым я работаю, поддерживающий многие приятные возможности GWT, включая разделение кода и управление историей, с простым API на основе аннотаций. Он появился совсем недавно, но уже используется в ряде проектов.