Действия Asp.Net MVC - принцип разделения интересов / принцип единой ответственности

Question

В информатике нас учили, что каждый метод должен делать одно и только одно. Я немного запутался тогда, когда мы видим действия MVC, такие как следующие , приведенные в качестве примеров хорошей практики :

    [AcceptVerbs(HttpVerbs.Post), Authorize]
    public ActionResult Edit(int id, FormCollection collection) {

        Dinner dinner = dinnerRepository.GetDinner(id);

        if (!dinner.IsHostedBy(User.Identity.Name))
            return View("InvalidOwner");

        try {
            UpdateModel(dinner);

            dinnerRepository.Save();

            return RedirectToAction("Details", new { id=dinner.DinnerID });
        }
        catch {
            ModelState.AddModelErrors(dinner.GetRuleViolations());

            return View(new DinnerFormViewModel(dinner));
        }
    }

В основном этот фрагмент кода предоставляет множество функций:

1. Определяет, как получить доступ к действию - только публикация
2. Определяет, кто может получить доступ к действию - Авторизоваться
3. Доступ к механизму персистентности - ужинРепозиторий
4. Доступ к информации о состоянии - (User.Identity.Name)
5. Преобразует NameValueCollection в строго типизированный объект - UpdateModel ()
6. Указывает 3 возможных ActionResults и содержимое для каждого - InvalidOwner / Details / Редактировать представления

Мне кажется, это слишком много обязанностей для одного метода. Это также довольно простое действие, т. Е. Оно не касается общих сценариев, таких как:

1. Проверка бизнес-правил - «Никогда не доверяйте вводу пользователя»
2. Пути навигации - при успешном сохранении всегда возвращается «Подробности»
3. Различные типы возвращаемых данных. Кто-то хочет вызвать «Edit» из сетки и нуждается в JsonResult?
4. Лучшая обработка ошибок - YSOD, если база данных недоступна во время GetDinner (id)
5. Построение дополнительных данных представления - списки выбора для выпадающих списков

Не слишком упоминать объем тестирования, требуемого для этого единственного метода, то есть насмешки / подделки для FormCollection / UserIdentity / Authorization Provider / Repository / etc.

Мой вопрос: как нам избежать того, чтобы в наши действия контролера впихивалось так много вещей?

Я склонен думать, что "мнения" - это отличная концепция, особенно "Принцип Громовой смерти". Хотя я испытываю большое уважение к парням, которые занимаются сборкой FubuMVC , и к причинам, стоящим за этим, мне нужно кое-что, что я могу использовать прямо сейчас.

Редактировать - Ну, похоже, я хотел что-то вроде этого - Мнение Контроллера . Мне нужно изучить его дальше, так как это для MVC Preview 5, поэтому мне, возможно, придется обновить его самому.

Answer 1

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

Понятно, что для этого требуется пара вещей, но они атомарны и четко определены. Если вам когда-либо понадобится изменить способ обновления этой части модели, это действие контроллера, которое нужно искать и обновлять.

Можно утверждать, что один из принципов Thunderdome, «контроллеры должны быть легкими», не соблюдается, поскольку здесь проверяется бизнес-правило. Но NerdDinner - очень тривиальное приложение, поэтому нет смысла помещать его в дополнительный слой.

Если вы обнаружите, что этот метод делает слишком много, возможно, вам следует найти язык, на котором запрещено размещать более одного оператора в методе.

Answer 2

Я немного смущен вашим постом. Сначала вы жалуетесь, что это действие делает много, а затем вы жалуетесь, что не делаете больше.

Отредактировано, чтобы добавить:

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

Answer 3

проблема, которую я имею с «принципом единой ответственности», заключается в том, что люди не всегда сегментируют события одинаково - одни более гранулированные, чем другие. так что казалось бы, что можно легко найти более детальное представление о действии во всех, но в самых тривиальных случаях.

Answer 4

Я думаю, что он все еще выполняет минимальные требуемые действия .. для этого "Действие" может не соответствовать абсолютной одиночной ответственности - но это одиночное действие

1. Атрибуты говорят ASP.NET, что этот метод будет работать только с HTTP.Post, и удостоверение, которое пытается его использовать, должно быть авторизовано. - Хорошая безопасность. Так что на данный момент ничего на самом деле не делается. Они просто говорят серверу, что проверять.

   то есть, если не HTTP.post метод не будет работать , а если нет, список не будет работать .

2. Существует проверка того, совпадает ли личность пользователя с обедом. - Проверка работоспособности.

3. Это основано на строгой проверке типов - делайте UpdateModel (ужин) - просто убедитесь, что текущие объекты в модели были обновлены с новыми данными, а затем хранилище вызывается для Save (). - Это все еще одна единица действия - обновление модели, чтобы мы могли вызывать сохранение и сохранение.

4. Проверки валидации обрабатываются в Catch, который добавляет RuleViolations в модель и возвращает пользователя обратно в представление-нарушитель, т. Е. Редактирует / создает частичное представление, которое передает ответную реакцию на это.

5. Если сохранение работает - оно просто перемещает «рабочий процесс» пользователя в Детали - то есть очищает форму из памяти и перемещает работу обратно в детали. ИМХО здорово, как - мы находимся в сценарии POST и вещи не валяются в памяти - хорошо.

6. Было бы проще не перемещать поток данных назад, а просто оставить в режиме частичного редактирования.