Я попытался это сделать, но я хочу ответить раз и навсегда.
У нас есть обсуждение на работе, можно ли поместить бизнес-логику в Модель.
Например, если вы хотите убедиться, что ваш идентификатор установлен в int в базе данных. можете ли вы сделать intval($id) в классе модели? или если ввод текста слишком короткий. или вы «должны» делать это в контроллере?
Каков правильный путь?
Для меня такие вещи, как вычисления и другие вещи, которые вы не хотите в модели (должны быть очень чистыми), должны находиться в контроллере.
Прошу прощения за возможный дубликат.
Не стоит беспокоиться о том, где делать трансляции в int . Начните беспокоиться о том, что у вас, по-видимому, очень плохое понимание MVC (как это делают многие люди, к сожалению). Модель – это все . Модель моделирует ваше приложение. Модель представляет собой автономный блок, который представляет собой то, что делает ваше приложение.
Контроллер – это просто способ заставить вашу модель что-то сделать. Это клей между внешним миром и «вашим приложением». Контроллер получает запрос и на основании этого запроса решает, что должна делать модель. Затем в представлении предлагается просмотреть, что только что произошло, или дать пользователю некоторое представление о состоянии модели.
Я обычно думаю о структуре в терминах этого:
Модель – самый большой кусок. Он разбит на примитивы , которые представляют собой отдельные объекты (классы), которые представляют одну вещь в приложении (объект пользователя, почтовый объект); услуги , которые вы можете сделать («зарегистрировать пользователя», «создать сообщение»); и хранилище / базу данных , которая отвечает за управление хранением / извлечением примитивов из базы данных. Как именно они работают вместе и как именно вы их называете, зависит от вашего приложения, но это те концептуальные части, которые вам обычно нужно решать.
Представление представляет собой собственный слой, который может содержать или не содержать шаблоны.
Как вы видите, это большая часть работы, которую нужно выполнить приложению, контроллер – это самая маленькая ее часть. Контроллер в основном получает вход, вызывает службу модели и указывает, какой вид должен отображаться в ответ.
Чтобы понять, почему это разделение имеет смысл: спросите себя, как вы собираетесь использовать свое приложение . Типичным является наличие веб-сайта, на котором пользователи могут делать вещи. Но, возможно, вы также хотите иметь интерфейс API JSON для этого? Или клиент командной строки для административных задач? Оба этих сценария просто требуют различной обработки ввода и различного вывода. Но «регистрация пользователя» и «создание сообщения» – это те же действия, независимо от того, как они вызывается. Поэтому они принадлежат модели, вам нужен только немного другой контроллер и представление для создания JSON API или инструмента CLI. Во всем этом контроллер действительно является самой маленькой частью и не должен содержать бизнес-логику .
Жирные модели, тощие контроллеры.
Хорошо, что вы делаете кастинг в своей модели, так как тогда вы делаете это только в одном месте, а не в нескольких местах, где вы называете relavant setter в своих контроллерах. Если вы использовали установщик десять раз в десяти разных контроллерах, тогда вам нужно будет убедиться, что вы выбрали переменную в десяти разных местах.