Как применить SRP к классам пользовательского интерфейса?

Мое приложение использует структуру DI и следует практике «программы для интерфейса», где это необходимо.

Я использую внедрение конструктора, так как хочу явно видеть зависимости. Но теперь конструкторы моих классов формы принимают слишком много параметров (например, >= 4).

Вопрос: поскольку дизайн пользовательского интерфейса обычно не соответствует SRP, класс Winform может иметь n зависимости конструктора. Вам нравится оставлять их как есть, вместо этого передавать прокси-объект, использовать локатор службы...? Также вы вводите «аспекты» (логгер и т. д.) в каждый конструктор, учитывая, что не используется аоп-фреймворк?


dependency-injection c# winforms single-responsibility-principle
person henginy    schedule 18.01.2011    source источник

Ответы (1)


arrow_upward
4
arrow_downward

Нет никаких причин, по которым реализации пользовательского интерфейса не должны придерживаться SRP. Используя такие шаблоны, как MVP, MVC или MVVM, единственная обязанность класса пользовательского интерфейса заключается в отображении и сборе данных через пользовательский интерфейс. Часто это лучше всего делать с помощью довольно пассивных структур данных, таких как модели представления.

Проблема с чрезмерным внедрением конструктора должна быть решена с помощью рефакторинга. к Агрегированным службам.

Аспекты лучше всего решать с помощью применения шаблона проектирования Decorator.

person Mark Seemann    schedule 18.01.2011
comment
Спасибо! Обе статьи великолепны. Однако я хотел бы немного раскрыть SRP в части дизайна пользовательского интерфейса. Как вы справляетесь с нестандартными UI-требованиями заказчика? Например, формы, включающие несколько обязанностей (в соответствии с вашим дизайном)... Я думаю, что можно использовать составные представления, каждое из которых использует SRP сам по себе, или можно пересмотреть степень детализации обязанностей (как в Aggregate Services). Какой путь вы бы выбрали? - person henginy; 18.01.2011
comment
Соединения взглядов звучат очень разумно. Каждое обращение к маленькому подмножеству большего набора проблем. Это был в основном путь, по которому пошел ныне более или менее несуществующий Composite Application Block. - person Mark Seemann; 18.01.2011