Я пытаюсь понять концепцию «Fat» на моделях против «тощего» на контроллерах и из того, что я обсуждал, у меня есть следующий пример (это взято из обсуждения freenode):
Вопрос: В рамках парадигмы MVC, упомянутые модели Fat, тощие контроллеры. Я здесь думаю: если у меня есть много методов (на контроллере), которые используют только несколько абстрактных методов для CRUD (на модели), создаю ли вместо этого модель контроллера жира? Или они говорят, толстая модель, носящая в том, что возвращается и не набирается? это то, чего я никогда не понимал =) Любые комментарии оцениваются! большое спасибо
OBS1: Я не делаю то, что касается модели, в контроллере, у меня просто есть методы, которые контролируют то, что происходит с моделью
OBS2: скажем, «checkIfEmailExists ()», имеет «john@hotmail.com» в качестве параметров. Этот метод будет получать возврат из метода модели, который запрашивает, если этот параметр существует в таблице, возвращает boolean. Если равно 0, «checkIFemailExists ()» вызовет другой метод модели, этот, он просто еще один абстрактный метод, который выполняет операцию обновления.
OBS3: «checkIfEmailExists ()», не просто контроллер? Он на самом деле не выполняет CRUD, он просто сравнивает ценности и т. Д. Это меня путает, потому что в моей голове это контроллер: S
Примечания: Я думаю, что это не лучший пример, так как «проверить, существует ли что-то», похоже на запрос моей таблицы
Q2: еще один вопрос, поэтому, допустим, у меня есть форма представления, откуда отправляется этот параметр адреса электронной почты. Вы говорите, что представление идет непосредственно к модели?
Q3: Должен ли контроллер действовать между ними? это парадигма
ЗАКЛЮЧИТЕЛЬНОЕ ПРИМЕЧАНИЕ. Дискуссия закончилась, сказав, что я ошибаюсь, желание – это нормально (я изучаю). Но, так, какие правильные ответы для Q2 и Q3?
Спасибо за ваше внимание
Ваша заявка – M. Она должна быть независимой от V и C. V и C образуют пользовательский интерфейс для вашего приложения. Независимо от того, является ли это веб-интерфейсом или интерфейсом командной строки, для основной бизнес-логики вашего приложения не должно иметь значения. Вы хотите, чтобы модель была жирной с бизнес-логикой.
Если вместо этого у вас есть контроллер жира, например, полный бизнес-логики, вы не придерживаетесь цели MVC. Единственная ответственность контроллера – обработка и делегирование запросов пользовательского интерфейса к модели. Вот почему он должен быть тощим. Он должен содержать только код, необходимый для того, за что он несет ответственность.
public function fooAction() { if(isset($_POST['bar'])) { $bar = Sanitizer::sanitize($_POST['bar']); $rows = $this->database->query('SELECT * from table'); try { foreach($rows as $row) { $row->foo = $bar; $row->save(); } } catch (Exception $e) { $this->render('errorPage'); exit; } $this->render('successPage'); } else { $this->render('fooPage'); } } Когда это должно быть
public function fooAction() { if(isset($_POST['bar'])) { $success = $this->tableGateway->updateFoo($_GET['bar']); $page = $success ? 'successPage' : 'errorPage'; $this->render($page); } else { $this->render('fooPage'); } }
потому что это все, что нужно знать контроллеру. Он не должен обновлять строки. Он должен просто сказать модели, что кто-то запросил это изменение. За обновление отвечает класс, управляющий строками. Кроме того, контроллер не обязательно должен дезинфицировать значение.
Что касается Q2 и Q3, см. Мой ответ на Могу ли я вызвать модель из представления .
Я давно работаю с парадигмой MVC, и я могу поделиться с вами своим опытом.
«Модельная» часть отвечает за обработку всего материала, который не является строго «веб-сайтом», например, проверки, логики, доступа к данным и т. Д. Подумайте об этом как о смешанном уровне бизнес-уровня + доступа к данным. Вы также можете иметь BLL + DAL в отдельных сборках и использовать часть «Модель» MVC в качестве моста между вашим BLL и вашим приложением, а также добавлять классы, характерные для приложения MVC, и не относящиеся к BLL, такие как классы ViewData , и т.д.
Часть «контроллер» – это то, что заботится о веб-специфических материалах, таких как аутентификация, куки, GET и POST, querystrings и т. Д. Он использует материал, присутствующий в модели и / или BLL, и отправляет данные, которые должны быть отображены для пользователей к представлениям.
«Представления» – это ваши html-шаблоны, которые могут получать данные от контроллера и отображать их. Никаких логических операций в представлениях никогда не должно быть сделано, поэтому никаких операторов «if», никаких циклов и т. Д. Если вы обнаружите, что у вас такие потребности, вам нужны некоторые «вспомогательные» методы, которые создают желаемый html, а затем вызывают их из Посмотреть. Таким образом, только данные получают данные и предлагают пользовательским ссылкам / формам отправлять данные контроллеру, но они ничего не выдумывают.
Надеюсь, это устранит некоторые из ваших сомнений.
Я всегда интерпретировал это как означающее, что модели должны инкапсулировать логику, связанную с этими моделями, в более объектно-ориентированный подход, в отличие от того, чтобы вся логика в контроллерах использовалась в более процедурном подходе. Процитировать Собор и Базар :
Интеллектуальные структуры данных и немой код работают намного лучше, чем наоборот.
Я могу показать свое смещение (в сторону C #), но я не думаю, что имеет смысл говорить о MVC, если вы не используете стиль объектно-ориентированного программирования. Контроллер не является методом, он представляет собой набор методов, сгруппированных в класс, каждый из которых обрабатывает некоторый ввод (url / request). Модель не является способом доступа к базе данных (это уровень доступа к данным), это набор свойств и методов, которые инкапсулируют какой-либо идентифицируемый объект в ваше приложение: лицо, заказ, продукт и т. Д. Лучший способ подумайте, что контроллеры обрабатывают ввод, модели содержат данные, но, конечно, это упрощено.
Для меня вопрос о «жире» и «тощий» – это вопрос, где живет ваша бизнес-логика. Если у вас много логики в вашем контроллере, а не просто обработка ввода, но реализация бизнес-логики, то ваш контроллер относительно толще, чем если вы просто используете их для перевода запросов в сборки моделей, которые передаются в представление для рендеринга , По моему опыту, это не всегда решение. Много времени у вас есть бизнес-логика (валидация, поддержание отношений, аудит) в модели, в то время как у вас есть логика приложения (проверка разрешений, дезинфекция и т. Д.) В контроллере тоже.
Я думаю, что хорошее разделение между контроллером и моделью можно было бы сделать, если позволить контроллеру выполнять «синтаксические» зависимые операции без какой-либо бизнес-логики и использовать модель для выполнения «семантических» операций.
Хорошим примером такого разделения является:
вы можете выполнить проверку регулярного выражения электронной почты в контроллере, но вы не будете выполнять сопоставление ldap этого сообщения в контроллере.