PHP MVC и SQL минус модель

Question

Я читал несколько статей о MVC и у меня было несколько вопросов, на которые я надеялся, что кто-то может помочь мне ответить.

Во-первых, если МОДЕЛЬ является представлением данных и средством, с помощью которого можно манипулировать этими данными, тогда для доступа к данным (DAO) с определенным уровнем абстракции с использованием общего интерфейса должно быть достаточно большая задача, не так ли?

Для дальнейшего уточнения этого вопроса, скажем, большая часть моей разработки выполняется с использованием MySQL в качестве основного механизма хранения моих данных, если я избегаю специфических функций вендора (например, UNIX_TIMESTAMP) - при построении моих операторов SQL и использовал абстрактный объект БД, имеющий общий интерфейс, перемещающийся между MySQL и, возможно, PostgreSQL, или MySQL и SQLite должны быть простым процессом.

Вот то, что я получаю в какой-то задаче, обрабатываются одним CONTROLLER - (т. Е. UserRegistration) и, скорее, создав MODEL для этой задачи, я могу получить экземпляр объекта db - (то есть DB :: getInstance ()) - затем делает необходимые вызовы db для ВСТАВКИ нового пользователя. Почему с такой простой задачей я должен создать новую МОДЕЛЬ ?

В некоторых примерах, которые я видел, создается MODEL , и в этом MODEL есть оператор SELECT, который выбирает x количество заказов из таблицы заказов и возвращает массив. Зачем это делать, если в CONTROLLER вы создаете еще один цикл для итерации по этому массиву и присвойте его VIEW ; ех. 1

ех. 1: foreach ($list as $order) { $this->view->set('order', $order); }

Полагаю, можно изменить возвращаемое значение, так что это возможно; ех. 2.

ех. 2: while ($order = $this->model->getOrders(10)) { $this->view->set('order', $order); }

Полагаю, мой аргумент заключается в том, что зачем создавать модель, когда вы можете просто сделать необходимые вызовы БД из вашего CONTROLLER , предполагая, что вы используете объект БД с общим интерфейсом для доступа к вашим данным, как я подозреваю большинство сайтов используют. Да, я не ожидаю, что это практично для всех задач, но опять же, когда большая часть того, что делается, достаточно проста, чтобы не обязательно требовать отдельной МОДЕЛИ .

В настоящее время пользователь делает запрос «www.mysite.com/Controller/action/args1/args2», фронт-контроллер (я называю это маршрутизатором) переходит к контроллеру (классу), и внутри этого контроллера вызывается определенное действие (метод), и оттуда создается соответствующий VIEW , а затем выводится.

Answer 1

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

Однако есть и другие потенциальные преимущества разделения MVC:

• В контроллере вообще нет SQL: может быть, вы решили собрать свои данные из источника, отличного от базы данных (массив в сеансе? Фиктивный объект для тестирования? Файл? Просто что-то еще), или схема вашей базы данных изменения, и вам нужно искать все места, где должен измениться ваш код, вы можете просматривать только модели.
• Разделение наборов навыков. Может быть, кто-то из вашей команды отлично справляется со сложными SQL-запросами, но не очень хорошо справляется со стороной php. Тогда чем более разрозненным будет код, тем больше людей смогут сыграть на своих сильных сторонах (тем более, когда дело касается html / css / javascript).
• Концептуальный объект, представляющий блок данных: как сказал Стивен, есть разница в преимуществах, которые вы получаете от независимости от базы данных (так что вы можете переключаться между mysql и postgresql при необходимости) и от schema независимость (поэтому у вас есть объект, полный данных, которые хорошо сочетаются друг с другом, даже если они получены из разных реляционных таблиц). Если у вас есть модель, представляющая хороший блок данных, вы сможете использовать эту модель более чем в одном месте (например, личную модель можно использовать при входе в систему и при отображении списка персонала).

Я, конечно, считаю, что идеалы разделения задач MVC очень полезны. Но со временем я пришел к выводу, что с альтернативными стилями, такими как сохранение MVC-подобного разделения с функциональным стилем программирования, в php легче справиться, чем с полноценной ООП-системой MVC.

Answer 2

Я нашел эту замечательную статью, в которой были рассмотрены большинство моих вопросов. В случае, если у кого-то еще были подобные вопросы или было бы интересно прочитать эту статью. Вы можете найти его здесь http://blog.astrumfutura.com/archives/373-The-M-in-MVC-Why-Models-are-Misunderstood-and-Unappreciated.html.

Answer 3

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

Если вы считаете свою модель пользователя реальным человеком, а не частью данных. Если вы хотите узнать, как зовут людей, проще позвонить в центральный офис по телефону (в базе данных) и запросить имя или просто спросить человека: «Как вас зовут?» Это одна из идей модели. Проще говоря, вы можете рассматривать свои модели как реальные живые существа, а методы, которые вы к ним привязываете, позволяют вашим контроллерам задавать этим живым существам ряд вопросов (IE - можете ли вы просмотреть эту страницу? Вы вошли в систему? Какой тип изображение вы? вы опубликовали? когда вы были последний раз изменены?). Ваш контроллер должен быть тупым, а модель - умной.

Другая идея состоит в том, чтобы хранить работу SQL в одном центральном месте, в данном случае - в ваших моделях. Так что у вас нет ошибочного SQL, плавающего вокруг ваших контроллеров и (в худшем случае) ваших представлений.