В MVC считается ли хорошей практикой иметь частные, не действующие функции в классе контроллера?

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

Будет ли хорошей практикой разбивать эти огромные функции действия на более мелкие частные функции в классе контроллера или необходимость такой оптимизации означает, что мы должны добавить их в модель?

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

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

Вы можете применить несколько ту же логику к вашему MVC-приложению. Огромные и неприятные функции, которые вы описываете, являются наиболее вероятным поведением модели, и они должны принадлежать модели (обратите внимание, что модель - это не только объект, который отображается в представлении). Если поведение модели меняется, то должна меняться модель, а не контроллер, который ее обрабатывает.

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

Лучший ответ, который я могу дать, это процитировать замечательную книгу Роберта Мартина «Чистый код», которую я настоятельно рекомендую всем, кто интересуется этой темой:

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

Лучше сказать не могу. Применяется еще одна замечательная цитата из той же книги:

Функции должны делать одно. Они должны делать это хорошо. Они должны это делать только.

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

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

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

Необходимая логика и вспомогательные функции помещаются в отдельные автономные вспомогательные классы. Это также значительно облегчает мое тестирование (вы тестируете .. правильно ??: D) Тестирование контроллеров, как известно, сложно, каждый раз, когда вы пытаетесь создать экземпляр контроллера для тестирования, вы должны думать о HTTP-контексте и подделке. http это и то, и это боль, но это боль нарочно. Вам нужно все это, потому что контроллер так тесно связан с HTTP и сетью. Это точка входа в ваше веб-приложение.

Логические и вспомогательные функции не имеют ничего общего с сетью. Они полностью независимы от окружающей среды (или должны быть). Одно это должно сказать вам, что они не принадлежат друг другу в одном месте. Кроме того, если вы привязываете всю логику своих приложений к Интернету или конкретной веб-реализации, вы никогда не сможете взять ее с собой.

Мы разработали наш сайт MVC со всеми нашими объектами базы данных (не нашими моделями mvc, нашими фактическими объектами db), нашим хранилищем, нашими вспомогательными классами и нашей логикой в ​​отдельных автономных библиотеках DLL. У нас только у каждого был один веб-сайт, но мы все равно сделали это так.

Несколько месяцев назад нас попросили создать несколько настольных приложений, связанных с некоторыми из наших периферийных систем. Это было легко сделать, так как весь наш протестированный код можно было легко использовать повторно. Если бы мы вставили наш код в наш веб-проект или вставили в наши контроллеры, мы бы никогда не смогли этого сделать.

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

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

Всегда помните принцип KISS: будь проще, глупее.