Использование Ninject для внедрения зависимостей во внешние объекты (пользовательский контроль)

Я хотел бы использовать Ninject в своем приложении WinForms. Я не могу понять, как использовать его для своих пользовательских элементов управления. Иногда они полагаются на сервисы, которые я хочу настроить через платформу DI. Эти элементы управления должны быть управляемыми через конструктор (для этого нужны конструкторы по умолчанию).

Итак, есть ли способ ввести зависимости в свойства этого пользовательского элемента управления? Поскольку дизайнер должен уметь его построить, kernel.Get<TestClass> здесь работать не будет. Есть ли метод или какой-то код, который позволит мне «заполнить» зависимости в методе Form_OnLoad()?

Я также могу вспомнить другие примеры, в которых я хотел бы внедрить в свойства уже существующего объекта, но пользовательский элемент управления WinForms объяснить проще всего.


dependency-injection winforms ioc-container ninject
person Nathan    schedule 24.01.2010    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Я думаю, вам нужно перевернуть свое мышление. В Model View Controller у View есть только одна обязанность: отображать данные.

За то, как эти данные попадают туда, отвечает Контроллер, а то, как данные представлены в памяти, определяет Модель.

Хотя для Windows Forms не существует конкретных фреймворков MVC, можно создать грубые фреймворки вручную или взглянуть на (теперь уже вышедший на пенсию) Composite Application Block, чтобы получить представление о том, как это можно сделать (хотя CAB, возможно, слишком сложен для большинства людей). Сегодня доступны более элегантные варианты, но они включают в себя WPF.

В любом случае, вместо того, чтобы вводить ваши зависимости в ваши представления, вставьте их в контроллеры, и пусть контроллеры создают и правильно заполняют представления (ваши элементы управления).

Таким образом, вы можете защитить свои элементы управления от проблем с DI, как и должно быть.

person Mark Seemann    schedule 24.01.2010
comment
Хорошо, я вижу, что у контроллеров в конечном итоге должны быть зависимости. Я делал MVC с созданным сначала представлением, а затем он создает контроллер. Поскольку пользовательские элементы управления всегда будут создаваться формой или другими элементами управления, следует ли создавать контроллеры по отдельному пути? - person Nathan; 25.01.2010
comment
Я ошибаюсь в использовании kernel.Inject (myControl), когда myControl имеет свойства, которым присвоено значение [Inject]? - person Nathan; 25.01.2010
comment
Вы можете делать это, если понимаете, что это означает зависимость от самого Ninject. - person Mark Seemann; 25.01.2010
comment
использование kernel.Inject(myControl) также несколько близко к шаблону локатора служб, который часто не рекомендуется. Вы можете немного обмануть и по-прежнему использовать инъекцию конструктора с winforms, пометив свой конструктор без аргументов как закрытый (чтобы конструктор форм все еще работал), а затем использовать инъекцию конструктора (не забывая вызывать либо конструктор без аргументов, либо InitializeComponent()), чтобы составить ваше приложение во время выполнения. - person FMM; 09.01.2013

arrow_upward
1
arrow_downward

Я думаю, вопрос в том, какой инструмент DI вы можете использовать, чтобы получить инъекцию зависимостей для работы с формами Windows. Все используют пример MVC, потому что его легко реализовать (тот же пример, если он витает вокруг нас, как если бы он был новым и оригинальным). Если у вас есть ответ на этот вопрос с помощью winforms или даже WPF - это будет полезно.

Этот ответ здесь в основном говорит - в любом случае, я не знаю, поэтому вводите их в контроллеры и заполняйте представления - правда? Вернуться к MVC? Опять же - winforms.

person MOP    schedule 26.05.2011
comment
Не совсем понял ваш второй абзац. Вы хотите сказать, что отвечающие люди не должны предлагать в качестве решения переход на MVC? Лично я использую ASP.NET WinForms и не планирую переписывать большие приложения в MVC. - person Chris Walsh; 22.03.2016