ASP.NET MVC - когда SRP и DRY кажутся конфликтующими

Question

Мои самые простые контроллеры ASP.NET MVC 2 выполняют вызовы моего уровня обслуживания и сопоставляют модели представлений с сущностями, использующими AutoMapper.Все выглядит фантастически, и нет повторяющегося кода.

Однако, когда я попадаю в сценарии, где у меня подобное поведение, у меня возникают проблемы с балансировкой принципа единой ответственности (SRP)с Не повторяйся (СУХОЙ).Примером этого может быть необходимость добавления / редактирования транспортных средств, в которых некоторые свойства / поведение являются общими, в то время как другие являются уникальными для конкретного транспортного средства.

Если я стремлюсь к действительно тонким контроллерам (таким образом соблюдая принцип единой ответственности),Я заканчиваю тем, что повторяю код и в представлениях, и в контроллерах с небольшими изменениями (заголовок, метки полей, видимость полей, значения раскрывающегося списка, критерии выбора и т.связывание слишком большого количества логики в одном контроллере / представлении, и оно становится раздутым.

Каковы некоторые способы адресации повторяющегося кода в контроллерах / представлениях?Я не говорю о коде базы данных, который может быть передан в хранилище.Я не говорю о бизнес-логике, которая может быть учтена на уровне обслуживания.Я ищу инструменты и / или практические правила, которые помогут мне найти лучшее решение в сценарии, описанном выше.

Answer 1

Вы получаете:

• partials
• RenderAction
• фильтры действий
• сервисный уровень и вспомогательные классы (не HtmlHelper)
• связующие модели
• базовые контроллеры
• внедрение зависимостей

Таким образом, ваши представления могут вызывать общие частичные / действия для похожих частей, общие данные могут быть подготовлены фильтрами действийкод доступа к базе данных может быть скрыт в связывателе смарт-модели, или у вас может быть родительский контроллер, который дочерние контроллеры переопределяют с помощью определенных настроек.И, конечно же, старые добрые сервисные уровни, где вы просто извлекаете общий код в вспомогательные / статические методы или, что еще лучше, внедряете конкретные реализации.

Ничего нового, такие же старые приемы.

Или, может быть, ваши контроллеры делают слишком много работы?Вот где вещи выше также помогают.ASP.NET MVC имеет очень хорошие инструменты для сокрытия кода уровня инфраструктуры и удаления его от контроллеров.А если это не инфраструктура - скорее всего, это относится к домену.Там вы можете использовать наследование, композицию и другие трюки ООП.

Конкретный пример.Предположим, что ваши контроллеры должны установить несколько свойств по-другому.

1. Вы можете иметь свои представления для этого, если это в основном форматирование или выбор того, какие свойства показывать
2. Вы можете иметь своисущности имеют виртуальные методы - т.е. код рефакторинга для перемещения решений на уровень домена вместо контроллеров
3. У вас могут быть вспомогательные классы ViewDetails, которые будут принимать ваши сущности и получать данные на основе того, что вам нужно;это немного подвох, но иногда полезно;Вы делегируете решение другому классу «стратегии»
4. . Вы можете использовать фильтры действий для добавления этих данных в ViewData или для настройки определенных типов ViewData.Model (ищите некоторый его интерфейс).
5. У вас может быть абстрактный контроллер, в котором дочерние элементы передают подробности реализации в базовый конструктор, например (): base (repository => repository.GetSpecificData ())

и так далее.Я фактически использую их все в соответствующих местах.

Answer 2

Я рекомендую вам использовать SRP over DRY в этих случаях. Я написал здесь подробный ответ.

Короче говоря, оба являются правилами, которые помогают поддерживать ваш код в обслуживании. DRY - это механизм низкого уровня абстракции, а SRP - высокий уровень абстракции. При поддержке приложения структура высокого уровня абстракции важнее, чем низкий уровень абстракции.

В вашем случае я не считаю необходимым отказываться от СУХОГО.

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

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

Answer 3

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