GWT с пружинным внедрением зависимости
Может быть, это немного касательно, но я считаю, что файл конфигурации должен быть прочитан в словарь / хэш-таблицу значений ключей при первом запуске приложения и с этого момента всегда вызываться через этот объект для скорости. Обычно таблица ключ / значение начинается как строка за строкой, но вспомогательные функции в объекте делают такие вещи, как DateTime GetConfigDate (string key) и т. Д.
6 ответов
Guice поддерживается GWT с использованием GIN . Для Spring-подобного DI с GWT ознакомьтесь с GWT Toolbox или Rocket GWT .
Я считаю, что GIN - более естественный выбор для GWT. Не потому, что это тоже сделано Google, а потому, что использование XML для конфигурации GWT не имеет абсолютно никакого смысла. Все статически компилируется в JavaScript, поэтому нет необходимости во внешней конфигурации. Пусть ваши инструменты рефакторинга будут довольны; выберите GIN.
Чтобы ответить на ваш другой вопрос, вы не найдете многих фреймворков SE, которые работают с GWT. Прежде всего, он не поддерживает отражение или манипулирование байт-кодом (все это JavaScript), что сразу исключает множество фреймворков. Log4j, с другой стороны, не имеет смысла, потому что на стороне клиента нет доступной файловой системы, но есть библиотек , которые делают что-то по-другому.
Упомянутые выше библиотеки Spring для GWT в основном представляют собой переписанный вариант Spring для GWT. Они не делятся кодом со Spring просто потому, что не могут. Эти структуры работают, генерируя код («фабрики»), который подключает ваши компоненты, как если бы вы выполняли DI вручную.
Так же и работает GIN: он генерирует фабрики Java для ваших классов, а GWT компилирует его в оптимизированный JavaScript (что означает небольшие накладные расходы на производительность). Однако GIN негласно использует Guice для проверки конфигурации во время компиляции и проверки модулей.
Они не делятся кодом со Spring просто потому, что не могут. Эти структуры работают, генерируя код («фабрики»), который подключает ваши компоненты, как если бы вы выполняли DI вручную.Так же и работает GIN: он генерирует фабрики Java для ваших классов, а GWT компилирует его в оптимизированный JavaScript (что означает небольшие накладные расходы на производительность). Однако GIN негласно использует Guice для проверки конфигурации во время компиляции и проверки модулей.
Они не делятся кодом со Spring просто потому, что не могут. Эти структуры работают, генерируя код («фабрики»), который подключает ваши компоненты, как если бы вы выполняли DI вручную.Так же и работает GIN: он генерирует фабрики Java для ваших классов, а GWT компилирует его в оптимизированный JavaScript (что означает небольшие накладные расходы на производительность). Однако GIN негласно использует Guice для проверки конфигурации во время компиляции и проверки модулей.
Нет, вы не сможете этого сделать. Логика DI применяется во время выполнения на стороне сервера, а код GWT полностью выполняется на стороне клиента.
Интересно, поддерживается ли Guice (структура Google DI) GWT?
Это может быть альтернативой.
Я подумал, что будет проще просто создать Spring Controller, вызывающий метод doPost GWT RemoteServlet. Образец предоставлен здесь . Я знаю, что это немного по кругу. Но это защищает вас от изменений в реализации GWT, если таковые имеются ... Надеюсь, это поможет.
Spring ME может помочь вам здесь. Хотя я частично согласен с некоторыми из предыдущих ответов, приятно иметь одну и ту же парадигму программирования (и сантехники) для вашего клиентского и серверного кода.
Вы можете реализовать службу сервлетов на стороне сервера, которая извлекает объекты из Spring ApplicationContext, отрисовывая их в объекты JSon (я сделал это с помощью http: //json-lib.sourceforge. net / apidocs / net / sf / json / JSONSerializer.html ) в качестве примера. Тогда у вас может быть Singleton Facade Service, который делает запрос со стороны GWT-клиента нашей сервлетной службе.
Таким образом, вы можете получить инъекцию зависимостей времени выполнения на стороне клиента GWT.