Основная идея этого предложения в том, что в питоне ты можешь легко поменять как просто значение переменной, оставаясь в пределах одного типа, так и вообще поменять тип с одного на другой.
Страшнее дело обстоит, на мой взгляд, только в Objective-C, где ты можешь создать объект класса Кошка, а потом в реалтайме удалить у неё методы Мяукать() и Прыгать(), добавить методы ДышатьПодВодой() и Плавать(), однако, у тебя всё равно будет объект класса Кошка.
Да, то, что статья переводная и автор оригинальной статьи пишет
Правильные (и частые) вопросы. Обсуждение части этих вопросов можно найти в моих ранних статьях, поэтому сейчас мы посмотрим на проблему с другой стороны.
не умаляет проблемы с тем, что ответов на них нет. Давайте исправим это недоразумение.
Ответим на «Почему они должны быть тонкими?» и «Какой в этом плюс?».
Как уже правильно написали Rive, donotcodeit и Mikluho, плюсы тонких контроллеров в их читаемости, тестируемости, простоте поддержки и переиспользовании кода, вынесенного в сервис, вместо копипасты в разных контроллерах. От себя дополню список тем, что у контроллера должна быть только одна ответственность — работа с запросами на HTTP уровне. То есть, получить HTTP запрос и сделать вызов кода на обработку запроса, а также выбрать правильный HTTP код и заголовки для ответа в зависимости от результатов обработки.
Ответами же на вопросы «Как сделать их тонкими, если они сейчас не такие?» и «Как сохранить их тонкими?» как раз и занимается текущая статья — не нужно допускать лишний код в контроллеры, а если он там есть, то выносить.
Да, вы правы — это перевод, несмотря на это в комментариях уже написали множество хороших ответов: сокращение методов, стандартизация, тестирование, и так далее.
Самое главное, на мой взгляд, в том, что у контроллера должна быть только одна ответственность — работа с запросами на HTTP уровне. То есть, получить HTTP запрос и сделать вызов кода на обработку запроса, а также выбрать правильный HTTP код и заголовки для ответа в зависимости от результатов обработки.
Да, вы абсолютно правы. К сожалению, пока статья проходила ревью у модераторов у неё куда-то слетела метка, что это перевод. Хорошо хоть я в конце написал
Перевод статьи подготовлен в преддверии старта курса «C# ASP.NET Core разработчик».
но это в разы сложнее заметить, чем стандартную плашку о переводе и ссылке на оригинал. Спасибо вам большое, что заметили, вернул метку на место.
Основная идея этого предложения в том, что в питоне ты можешь легко поменять как просто значение переменной, оставаясь в пределах одного типа, так и вообще поменять тип с одного на другой.
Страшнее дело обстоит, на мой взгляд, только в Objective-C, где ты можешь создать объект класса Кошка, а потом в реалтайме удалить у неё методы Мяукать() и Прыгать(), добавить методы ДышатьПодВодой() и Плавать(), однако, у тебя всё равно будет объект класса Кошка.
В C# же ни первой, ни второй ситуации не бывает.
не умаляет проблемы с тем, что ответов на них нет. Давайте исправим это недоразумение.
Ответим на «Почему они должны быть тонкими?» и «Какой в этом плюс?».
Как уже правильно написали Rive, donotcodeit и Mikluho, плюсы тонких контроллеров в их читаемости, тестируемости, простоте поддержки и переиспользовании кода, вынесенного в сервис, вместо копипасты в разных контроллерах. От себя дополню список тем, что у контроллера должна быть только одна ответственность — работа с запросами на HTTP уровне. То есть, получить HTTP запрос и сделать вызов кода на обработку запроса, а также выбрать правильный HTTP код и заголовки для ответа в зависимости от результатов обработки.
Ответами же на вопросы «Как сделать их тонкими, если они сейчас не такие?» и «Как сохранить их тонкими?» как раз и занимается текущая статья — не нужно допускать лишний код в контроллеры, а если он там есть, то выносить.
Самое главное, на мой взгляд, в том, что у контроллера должна быть только одна ответственность — работа с запросами на HTTP уровне. То есть, получить HTTP запрос и сделать вызов кода на обработку запроса, а также выбрать правильный HTTP код и заголовки для ответа в зависимости от результатов обработки.