Архитектура клиент-сервер SmartGWT GWT
Мы планируем использовать интеллектуальные GWT, GWT и связанные с ними инфраструктуры для многофункционального интерфейса на стороне клиента и Spring MVC, который возвращает данные JSON на стороне сервера.
В рамках расследования, чтобы выяснить, соответствует ли оно нашему требованию, на следующие вопросы нужны ответы:
- Создание приложения GWT с нуля без использования каких-либо платформ потребует значительных усилий, чтобы следовать стандартному шаблону MVP. Но это более гибкий и тестируемый модуль, хотя и требует много времени. Лучшие практики GWT предлагают использовать шаблон проектирования MVP для создания более крупных приложений.
Smart GWT имеет свой собственный подход, где вы используете виджет, вводите в него источник данных, и все готово. Тем не менее, определить наилучшую практику создания таких интеллектуальных компонентов GWT в модульной (или MVP) форме. Какие-либо предложения
Использование фреймворка GWT-платформы и Smart GWT может быть опцией попробовать архитектуру MVP, как упомянуто здесь. Какие-либо предложения?
Валидация / отображение сообщений / исключений и поддержка других общих функций Smart GWT еще предстоит изучить.
Архитектура клиент-сервер: наличие ядра Spring MVC + Spring на стороне сервера и GWT + Smart GWT на стороне клиента может быть хорошим стеком технологий с открытым исходным кодом, но, учитывая, что GWT по умолчанию использует RPC для взаимодействия клиент-сервер, использование этих потребностей быть лучше оценены. (особенно аутентификация / обработка сессии / безопасность и т. д.). Какие-либо предложения?
Спасибо
3 ответа
Я никогда не использовал SmartGWT или любые другие богатые библиотеки. Мое мнение может быть предвзятым, но я действительно считаю, что компоненты Gwt легко настраиваются и легки. Это то, что я никогда не чувствовал из SmartGwt, это любая другая библиотека этого типа.
При этом, вот мой ответ на две ваши проблемы:
Использование фреймворка GWT-платформы и SmartGWT может быть опцией попробовать архитектуру MVP, как упомянуто здесь. Какие-либо предложения?
Ну, чтобы остаться MVP, как в этом аспекте, просто установите источник данных от докладчика. По вашему мнению, виджет SmartGWT должен быть "пассивным" и ожидать конфигурации, поступающей от докладчика.
Преимущество: вам не нужно тестировать представление, так как виджеты SmartGWT уже должны быть хорошо протестированы. Вам нужно только протестировать докладчика, где вы на самом деле вызываете представление, чтобы настроить этот виджет и убедиться, что вы вызываете его правильно.
Архитектура клиент-сервер: наличие ядра Spring MVC + Spring на стороне сервера и GWT + Smart GWT на стороне клиента может быть хорошим стеком технологий с открытым исходным кодом, но, учитывая, что GWT по умолчанию использует RPC для взаимодействия клиент-сервер, использование этих потребностей быть лучше оценены. (особенно аутентификация / обработка сессии / безопасность и т. д.). Какие-либо предложения?
RPC - это опция, а не связь по умолчанию. Существует два других типа связи (и даже больше, если вы попробуете экспериментальную функцию, такую как DeRPC): RequestBuilder и RequestFactory.
RequestBuilder может быть использован для HTTP GET с JSON Response. Не могу помочь вам с умным подходом GWT.
Вот пользователь Gwt-Platform, который использует Smart GWT, прочитайте его блог, он должен вас просветить: http://uptick.com.au/blog
На момент написания этого ответа блог был закрыт, но вскоре должен вернуться.
Сначала вы должны рассмотреть ваши цели в использовании MVP.
Если вы посмотрите на образцы SmartGWT, то обнаружите, что они уже содержат четкий и минимальный код. Вы не можете упростить или уточнить ни один из примеров, представив MVP, вы можете только добавить дополнительный код и сложность.
Таким образом, у вас должна быть очень конкретная и конкретная, очень убедительная причина, по которой вы хотите использовать MVP и вводить дополнительный код: конкретная цель разработки, которая не может быть достигнута более простым способом при обычном использовании SmartGWT.
Очень трудно найти правильную цель такого рода, потому что SmartGWT очень гибок и уже поддерживает тестирование через Selenium, и даже имеет расширения Selenium IDE и поддержку Selenium RC.
Возможный пример действительной причины для использования MVP может иметь две совершенно разные реализации представлений, одну в SmartGWT и упрощенную в простом GWT. Я знаю, что это не очень хороший пример, и трудно представить, что кому-то нужно это делать, но это потому, что нам еще не нужно, чтобы кто-то из разработчиков пришел и сформулировал причину использования MVP с SmartGWT, за исключением очень смутных представлений о гибкости.
Если вы собираетесь взять на себя задачу использования MVP, я думаю, вы должны понимать ситуацию достаточно хорошо, чтобы сказать что-то вроде "нам нужно сделать X, и если мы будем использовать SmartGWT в обычном режиме, это займет 6 месяцев, если мы добавим MVP, это займет 3". Насколько мне известно, никто никогда не идентифицировал такой сценарий.
В настоящее время я работаю над приложением Smart GWT / GWT.
Мое мнение о Smart GWT в настоящее время заключается в том, что он экономит много времени и предоставляет некоторые красивые и полезные виджеты. Тем не менее, поскольку это обертка вокруг библиотеки JavaScript, у нее есть некоторые предостережения, особенно при отладке. Зачастую это усложняет отслеживание ошибки, чем при использовании обычного GWT (или GWT с библиотекой, которая не была оболочкой JavaScript).
Чтобы попытаться прокомментировать ваши вопросы:
Я не нашел библиотеки Smart GWT, чтобы быть проблемой в этом отношении. Возможно, он отличается от рекомендованного GWT, но это не значит, что вам внезапно придется отказаться от всех лучших практик.
Не могу прокомментировать это - не нашел проблем с библиотеками проверки / сообщения / исключения
Мы используем JAX-RS для связи клиент-сервер, который Smart GWT изначально поддерживает и довольно прост в реализации. Возможно, это немного проще для отладки, чем GWT RPC, потому что он использует формат XML. Мы просто используем Spring Security для безопасности и, опять же, никаких проблем там нет.
Я думаю, что для нас главное, что заставило бы меня дважды задуматься об использовании Smart GWT снова, это настраиваемость: например, когда вы используете их формы, вы не можете с ними многое сделать с точки зрения макета. Smart GWT имеет свой собственный способ работы, и вы в значительной степени привязаны к нему, если не хотите писать свои собственные компоненты (что не идеально, потому что Smart GWT не рекомендует смешивать Smart GWT и простые компоненты GWT).
Если вы счастливы написать приложение, которое использует библиотеку Smart GWT и не требует особых настроек, это было бы хорошо.