Asp. Сетевые Действия MVC - Разделение Принципа Ответственности за Проблемы / Единственного Принципа Ответственности

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

Отредактировано для добавления:

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

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

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

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

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

Я думаю, что он все еще выполняет минимально необходимые действия .. для этого «Действие» может не соответствовать Абсолютной единственной ответственности - но это single action

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

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

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

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

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

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

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