Понимание MVC: каково понятие “Жира” на моделях, “Тощих” на контроллерах?
Я пытаюсь понять понятие "Жира" на моделях по сравнению с "тощим" на контроллерах и от того, что я обсуждал, у меня есть следующий пример (это взято из freenode обсуждения):
Q: На парадигме MVC, ее упомянутых моделях Fat, тощих контроллерах. Я здесь думаю, Если у меня есть много методов (на контроллере), который использует всего несколько абстрактных методов для CRUD (на модели), я создаю толстый контроллер вместо модели? Или они говорят, толстая модель, повторно боящаяся в том, что возвращается и не вводится? это - что-то, что я никогда не понимал =) Любые комментарии ценятся!Большое спасибо
OBS1: я не делаю то, что является ment моделью в контроллере, у меня просто есть методы, которые управляют тем, что идет в модель
OBS2: скажем, "checkIfEmailExists ()", имеет "john@hotmail.com", как параметры. Этот метод будет, получить возврат из образцового метода, который запросы, существует ли этот параметрический усилитель в таблице, возвратите булевскую переменную. Если будет 0, то "checkIFemailExists ()" назовет другой образцовый метод, этого, он - просто другой абстрактный метод, который выполняет операцию Обновления.
OBS3: "checkIfEmailExists ()", не просто контроллер? Он на самом деле не выполняет CRUD, он просто сравнивает значения и т.д. Это - то, что смущает меня, потому что в моей голове это - контроллер :S
Примечания: Я предполагаю, что это не лучший пример, начиная с высказывания "проверки, если что-то существует", походит запрос моя операция таблицы
Q2:just еще один вопрос, таким образом, скажем, у меня есть форма представления, от того, куда тот параметр адреса электронной почты отправляется от. Вы говорите, что представление переходит непосредственно к модели?
Q3:Shouldn't действие контроллера между ними? это - парадигма
ЗАКЛЮЧИТЕЛЬНОЕ ПРИМЕЧАНИЕ: законченное обсуждение, говоря, что я неправ, желание, в порядке (я учусь). Но, таким образом, каковы правильные ответы для Q2 и Q3?
Спасибо за Ваше внимание
5 ответов
Ваше приложение - это 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, см. Мой ответ на Могу ли я вызвать модель из представления .
Возможно, я показываю свою предвзятость (к C#), но я не думаю, что имеет смысл говорить о MVC, если вы не используете объектно-ориентированный стиль программирования. Контроллер - это не метод, это набор методов, объединенных в класс, каждый из которых обрабатывает некоторый вход (url/request). Модель - это не способ доступа к базе данных (это уровень доступа к данным), это набор свойств и методов, которые инкапсулируют некоторую идентифицируемую сущность в вашем приложении: человека, заказ, продукт и т.д. Лучше всего думать об этом так: контроллеры обрабатывают ввод, модели содержат данные - но, конечно, это упрощение.
Вопрос "толстый" или "тощий", на мой взгляд, это вопрос о том, где находится ваша бизнес-логика. Если у вас в контроллере много логики, связанной не с простой обработкой ввода, а с реализацией бизнес-логики, то ваш контроллер относительно толще, чем если вы просто используете его для преобразования запросов в сборки моделей, которые передаются представлению для визуализации. По моему опыту, это не всегда решение "либо/либо". В большинстве случаев бизнес-логика (валидация, поддержание отношений, аудит) находится в модели, а прикладная логика (валидация разрешений, санация и т.д.) - в контроллере.
Я думаю, что хорошее разделение между контроллером и моделью можно сделать, позволив контроллеру выполнять "синтаксически" зависимые операции без участия бизнес-логики и использовать модель для выполнения "семантически" связанных операций.
Хороший пример такого разделения:
вы можете выполнить проверку regexp электронной почты в контроллере, но вы не будете выполнять сопоставление ldap с этой почтой в контроллере.
Я давно работаю с парадигмой MVC и могу поделиться с вами своим опытом.
Часть «модель» отвечает за обработку всего, что не является строго «сетевым», например, проверки, логики, доступа к данным и т. Д. Думайте об этом как о разновидности смешанного бизнес-уровня + уровня доступа к данным. Вы также можете иметь BLL + DAL в отдельных сборках и использовать часть MVC «Модель» в качестве моста между вашим BLL и вашим приложением, а также добавлять классы, специфичные для приложения MVC и не связанные с BLL, например классы ViewData. и т. д.
«Контроллер» - это то, что заботится о специфичных для сети вещах, таких как аутентификация, файлы cookie, GET и POST, строки запросов и т. д. Он использует материал, присутствующий в модели и / или BLL, и отправляет данные, которые должны быть представлены пользователю в представлениях.
«Представления» - это ваши html-шаблоны, которые могут получать данные от контроллера и отображать их. В представлениях никогда не должны выполняться никакие логические операции, поэтому никаких операторов if, циклов и т. Д. Если вы обнаружите, что у вас возникли такие потребности, вам понадобятся «вспомогательные» методы, которые создают желаемый HTML и затем вызывают их из представления. Таким образом, представления только получают данные и предлагают пользователям ссылки / формы для отправки данных контроллеру, но они ничего не уточняют.
Надеюсь, это развеяло некоторые из ваших сомнений.
Я всегда интерпретировал это как означающее, что модели должны инкапсулировать логику, связанную с этими моделями, в более объектно-ориентированном подходе, в отличие от того, чтобы вся логика в контроллерах была более процедурной. подход. Процитирую Собор и базар :
Умные структуры данных и глупый код работают намного лучше, чем наоборот.