Клиент-серверная архитектура SmartGWT GWT

Я никогда не использовал SmartGWT или любые другие богатые библиотеки. Мое мнение может быть необъективным, но я действительно думаю, что компоненты Gwt легко настраиваются и легковесны. Я никогда не чувствовал, что SmartGwt - это какие-то другие библиотеки такого типа.

При этом вот мой ответ на два ваших вопроса:

Использование фреймворка GWT-platform и SmartGWT может быть вариантом опробовать архитектуру MVP, как упомянуто здесь. Какие-либо предложения?

Что ж, чтобы оставаться таким же MVP в этом аспекте, просто установите источник данных от ведущего. На ваш взгляд, виджет SmartGWT должен быть «пассивным» и ждать конфигурации, исходящей от ведущего.

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

Архитектура клиент-сервер: наличие ядра Spring MVC + Spring на стороне сервера и GWT + Smart GWT на стороне клиента может быть хорошим стеком технологий с открытым исходным кодом, но, учитывая, что GWT по умолчанию использует RPC для взаимодействия с клиентом и сервером, использование этих потребностей быть лучше оцененным. (особенно аутентификация / обработка сеанса / безопасность и т. д.). Какие-либо предложения?

RPC - это опция, а не связь по умолчанию. Есть два других типа связи (и даже больше, если вы попробуете экспериментальную функцию, такую ​​как DeRPC): RequestBuilder и RequestFactory.

RequestBuilder можно использовать для HTTP GET с ответом JSON. Не могу помочь вам с умным подходом GWT.

Вот пользователь Gwt-Platform, который использует Smart GWT, прочтите его блог, он должен вас просветить: http://uptick.com.au/blog

На момент написания этого ответа блог не работал, но вскоре он должен вернуться.

В настоящее время я работаю над приложением Smart GWT / GWT.

Мое мнение о Smart GWT в настоящее время заключается в том, что он действительно экономит много времени и предоставляет несколько красивых и полезных виджетов. Тем не менее, поскольку это оболочка для библиотеки JavaScript, у нее есть некоторые предостережения, особенно при отладке. Часто отследить ошибку гораздо сложнее, чем при использовании простого GWT (или GWT с библиотекой, которая не была оболочкой JavaScript).

Чтобы попытаться прокомментировать свои вопросы:

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

2. Не могу прокомментировать это - не обнаружил, что библиотеки проверки / сообщений / исключений являются проблемой

3. Мы используем JAX-RS для взаимодействия клиент / сервер, который Smart GWT изначально поддерживает и который довольно легко реализовать. Возможно, его немного проще отлаживать, чем GWT RPC, потому что он использует формат XML. Мы просто используем Spring Security для безопасности и, опять же, никаких проблем.

Я думаю, что для нас главное, что заставило бы меня дважды подумать об использовании Smart GWT, - это возможность настройки: например, когда вы используете их формы, вы не можете многое сделать с точки зрения макета. Smart GWT имеет свой собственный способ работы, и вы в значительной степени привязаны к нему, если не хотите писать свои собственные компоненты (что не идеально, потому что Smart GWT не рекомендует смешивать компоненты Smart GWT и простые компоненты GWT).

Если вы счастливы написать приложение, которое использует библиотеку Smart GWT и не требует особой настройки, это будет нормально.

Прежде всего, вы должны обдумать свои цели при использовании MVP.

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

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

Очень сложно найти действительную цель такого рода, потому что SmartGWT очень гибкий и уже поддерживает тестирование через Selenium и даже имеет расширения Selenium IDE и поддержку Selenium RC.

Возможным примером веской причины для достижения MVP может быть наличие двух полностью отдельных реализаций представления, одна в SmartGWT, а другая - в простом GWT. Я знаю, что это не очень хороший пример, и трудно представить, чтобы кому-то это понадобилось, но это потому, что у нас еще не появился разработчик и сформулировал причину использования MVP с SmartGWT, кроме очень расплывчатых представлений о гибкости.

Если вы собираетесь взять на себя задачу использования MVP, я думаю, вы должны понять ситуацию достаточно хорошо, чтобы сказать что-то вроде «нам нужно сделать X, и если мы обычно используем SmartGWT, это займет 6 месяцев, если мы добавим MVP, потребуется 3 дюйма. Насколько мне известно, такого сценария никто никогда не идентифицировал.