При создании проектируемого компонента .NET вы должны предоставить конструктор по умолчанию. ОтIComponent документация:

To be a component, a class must implement the IComponent interface and provide a basic constructor that requires no parameters or a single parameter of type IContainer.

Это делает невозможным внедрение зависимости через аргументы конструктора. (Могут быть предоставлены дополнительные конструкторы, но дизайнер их игнорирует.) Некоторые альтернативы, которые мы рассматриваем:

Service Locator

Don't use dependency injection, instead use the service locator pattern to acquire dependencies. This seems to be what IComponent.Site.GetService is for. I guess we could create a reusable ISite implementation (ConfigurableServiceLocator?) which can be configured with the necessary dependencies. But how does this work in a designer context?

Dependency Injection via properties

Inject dependencies via properties. Provide default instances if they are necessary to show the component in a designer. Document which properties need to be injected.

Inject dependencies with an Initialize method

This is much like injection via properties but it keeps the list of dependencies that need to be injected in one place. This way the list of required dependencies is documented implicitly, and the compiler will assists you with errors when the list changes.

Есть идеи, какая лучшая практика здесь? Как ты делаешь это?

editЯ удалил & quot; (например, WinForms UserControl) & quot; так как я намеревался вопрос о компонентах в целом. Компоненты все об инверсии управления (см. Раздел 8.3.1UMLv2 specification) поэтому я не думаю, что «вы не должны вводить какие-либо услуги»; хороший ответ

edit 2: Потребовалось некоторое время, чтобы поиграть с WPF и шаблоном MVVM, чтобы, наконец, «получить» Отметьте ответ. Теперь я вижу, что визуальный контроль действительно является особым случаем. Что касается использования невизуальных компонентов на поверхностях конструктора, я думаю, что компонентная модель .NET принципиально несовместима с внедрением зависимостей. Похоже, что он разработан вместо шаблона поиска сервисов. Может быть, это начнет меняться с инфраструктурой, которая была добавлена в .NET 4.0 вSystem.ComponentModel.Composition Пространство имен.