Как комбинировать проектируемые компоненты с внедрением зависимостей

Этот же вопрос мучил меня долгое время, пока я не понял, что думаю об этом неправильно. AFAIR, единственная причина для создания реализации IComponent - предоставить функции времени разработки - нет эффекта времени выполнения от реализаций IComponent.

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

Таким образом, ограничение на конструктор на самом деле является благословением, поскольку заставляет вас переосмыслить свой дизайн. Control - это программа, не зависящая от источника данных, которая отображает данные и взаимодействует с ними определенным образом. Пока эти данные соответствуют определенным интерфейсам и т. Д., Control доволен. Как поступают эти данные, не имеет значения для Control, и не должно быть. Было бы ошибкой позволить Control контролировать, как данные загружаются и изменяются.

В WPF это явно намного яснее, чем в Windows Forms: вы даете конкретному элементу управления DataContext и привязываете свойства элемента управления к членам этого DataContext. DataContext (который может быть любым объектом) исходит из-за пределов Control; это ответственность или ваш уровень презентации.

В Windows Forms вы по-прежнему можете сделать то же самое, назначив контекст данных элементу Control. По сути, это Property Injection - просто имейте в виду, что вам не следует внедрять сервисы; вам следует ввести данные.

Таким образом, я бы не согласился ни с одним из ваших предложений. Вместо этого позвольте элементу управления иметь одно или несколько свойств, которые позволяют назначать данные элементу управления, и используйте привязку данных для привязки к этим данным. Внутри реализации Control будьте готовы обработать ситуацию, когда нет данных: это будет происходить каждый раз, когда элемент управления размещается в VS во время разработки. Паттерн «нулевой объект» очень полезен для реализации такой устойчивости.

Затем настройте контекст данных из ваших контроллеров. Это способ MVC: элемент управления - это представление, но у вас должен быть отдельный контроллер, который может создавать и назначать модель для представления.