Внедрение зависимости только для сервисных текстовых объектов и одиночных элементов? (а НЕ для gui?)
Я в настоящее время экспериментирую с инверсией облика Google контейнера управления. У меня ранее были одиночные элементы для примерно любого сервиса (база данных, активный каталог) мое используемое приложение. Теперь я осуществил рефакторинг код: все зависимости даны как параметры конструкторам.Пока все хорошо. Теперь самая твердая часть с графическим интерфейсом пользователя. Я сталкиваюсь с этой проблемой: у Меня есть таблица (JTable) продуктов, перенесенных в ProductFrame. Я даю зависимости как параметры (EditProductDialog).
@Inject
public ProductFrame(EditProductDialog editProductDialog) {
// ...
}
// ...
@Inject
public EditProductDialog(DBProductController productController, Product product) {
// ...
}
Проблема состоит в том, что облик не может знать, какой продукт я выбрал в таблице, таким образом, это не может знать, что ввести в EditProductDialog.
Внедрение зависимости является довольно вирусным (если я изменяю один класс для использования внедрения зависимости, я также должен изменить все другие классы, это взаимодействует с), таким образом, мой вопрос разве, я должен непосредственно инстанцировать EditProductDialog? Но затем я должен был бы передать вручную DBProductController EditProductDialog, и я должен буду также передать его ProductFrame, и все это сводится к не использованию внедрения зависимости вообще.
Или мой дизайн испорчен, и из-за этого я не могу действительно адаптировать проект к dependecy инжекции?
Дайте мне некоторые примеры того, как Вы использовали внедрение зависимости с графическим интерфейсом пользователя. Всеми примерами, найденными в Интернете, являются действительно простые примеры, где Вы используете некоторые сервисы (главным образом базы данных) с внедрением зависимости.
5 ответов
Из того, что я вижу в вашем примере кода, я не уверен, что передача Product в EditProductDialog является лучшим дизайном, это означает, что вы не можете повторно использовать один и тот же диалог для двух разных продуктов.
В общем, я бы предпочел добавить setProduct (Product) в EditProductDialog , чтобы:
- включить повторное использование того же диалогового окна
- разрешить внедрение конструктора сам диалог
Кроме того, вы также можете, если хотите сохранить текущие аргументы конструктора, взглянуть на Guice Assisted Injection , который позволит вам вводить все зависимости в конструктор, при этом явное предоставление продукта.
Наконец, вы можете взглянуть на Guts-GUI , фреймворк с открытым исходным кодом для создания графических интерфейсов Swing с помощью Guice (все еще в разработке, но уже готов к использованию). В нем есть образец приложения, которое содержит примеры многоразовых диалогов.
Зависит от того, что мы подразумеваем под «графическим интерфейсом пользователя».
Я бы не стал использовать DI для JSP, но я бы использовал его в контроллерах, которые с ними взаимодействуют. Я считаю контроллеры частью пользовательского интерфейса. Я добавляю валидаторы, картографы и сервисы, необходимые им для выполнения запросов и создания ответов.
Если вы согласны, то DI подходит для слоя просмотра.
Составной графический интерфейс , безусловно, может использовать DI. Тем не менее, вы должны быть догматичны в отношении сохранения композитной ориентации. Любая прямая связь между элементами интерфейса создаст много головной боли.
Я считаю, что использование Guice при разработке графического интерфейса рабочего стола лучше всего подходит для настройки службы.
При вашем подходе вам нужно будет правильно настроить области взаимодействия, чтобы иметь возможность правильно внедрять в сервисы объекты пользовательского домена, выбранные в графическом интерфейсе.
Вместо этого вы можете сделать данные выбора доступными из сервиса, который внедряется как одноэлементный сервис в другие сервисы, которым требуются данные выбора.
SelectionService может выглядеть примерно так
public interface SelectionService {
Product getSelectedProduct();
// ...
}
При разработке веб-интерфейса у вас есть, например, область сеанса и запроса. Я считаю, что в программировании графического интерфейса рабочего стола сложнее определить область видимости, поэтому я бы выбрал DI для одноэлементных служб и подключения статических компонентов графического интерфейса и ручного создания экземпляров для всего остального.
И если вам нужно сделать данные Selection доступными как службу, то фрагмент кода может помочь.
Проблема в том, что guice не может знать какой продукт я выбрал в таблица, поэтому он не может знать, что вводить в EditProductDialog.
Используйте внедрение зависимостей для зависимостей, которые могут быть разрешены Guice (при запуске приложения). Используйте аргументы метода для установки любого состояния ваших служб, которое определяется логикой приложения и, следовательно, известно только позже, во время выполнения.
В этом конкретном случае код, который решает, какой продукт показывать (предположительно, ProductFrame, который знает выбор в таблице), перед его отображением вызовет метод SetProduct в диалоговом окне.