MVC в PHP??????

Question

[rgen3]

Уважамые хабравчане!



Приступил к изучению паттернов проектирования в PHP. Уже неделю не могу найти доступной информации на просторах интернета.



Поделитесь, пожалуйста, опытом с чего начать, что почитать и где найти простую информацию по этой теме.



Находил много материала по asp.net, но изучать хотелось бы именно на примере php.



И еще один вопрос: какие аналоги модели mvc вы можете предложить?

Answer 1

[egorinsk]

Что значит аналоги MVC? Есть модификации MVC типа MVVM или MVP (по сути, примерно то же), есть 3-tier архитектура (но вряд ли вы захотите ее делать на PHP).

Я осваивал MVC на примере CakePHP (хотя сам фреймворк мне не нравится, он тупой, но как учебный пример годится). Просто прочтите прилагаемый к нему мануал, где приведен пример, как сделать блог с использованием подхода MVC.

Паттерны вам пока не нужны. Все паттерны описаны в какой-то книге Мартина Фаулера (вот список: martinfowler.com/eaaCatalog/, там есть перевод на русский, но он плохой ), но, чтобы их понять, надо сначала иметь определенный опыт написания кода и разбора чужого кода. Если его у вас нет, для вас эти паттерны будут чем-то чужеродным и непонятным (много умных слов, а зачем это нужно, если можно по-простому написать).

Если вас (вдруг) интересуют паттерны, чтобы писать более аккуратный, качественный, профессиональный и поддерживаемый код, тут лучше руководствоваться общепризнанными принципами:

— DRY (не повторяйся) — не должно быть повторяющихся кусков в коде длинее нескольких строк, не должно быть генерации кода путем копипасты и правки, какие-то данные (к примеру, список стран) должны храниться только в 1 месте, а не в нескольких. Следование этому принципу улучшает архитектуру кода, упрощает поддержку.

— KISS (делай как можно проще) — выбирай самый простой способ реализации, если есть несколько вариантов, и если это не грозит проблемами в будущем.

— не ориентируйся и не используй фичи из PHP4. Он умер.

— не полагайся только на HTML5/CSS3. Еще не у всех есть айпады с маками, и живы ИЕ8, ИЕ7 и ИЕ6.

— пиши свой код, так, как будто после тебя его будет поддерживать псих-маньяк, который знает, где ты живешь. То есть, не пиши такие вещи, которые трудно/невозможно понять другому человеку. Думай о том, кто будет читать твой код. Изредка в сложных местах ставь комментарии. Не раскидывай логику выполнения действия по 10 файлам. Не делай файлы больше 500-1000 строк.

— давай правильные названия классам, функциям, константам и переменным. Не используй транслит ($chisloPokupatelei). Не знаешь английский — вооружись Яндекс.Словарями/Гуглотранслейтом. Выбери и следуй стандарту кодирования (рекомендую Zend Coding Standard).

— код на функциях можно легко превратить в ООП-код путем превращения функций в статические методы и объединения в классы.

Comments

[egorinsk]

А, еще вдогонку. Про именование функций. Не называй функции в стиле do*, типа doMakeRequest() или doConnect() — это реально уродливо смотрится, особенно когда там же есть функция connect() и остается гадать чем она отличается от doConnect().

[Владимир Чернышев]

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

И толком никакого профита не получить. Если уж менять функции на методы, то на методы объектов, а не классов, а в месте вызова функции инстанцировать объект и вызывать метод. Кроме всего прочего это иногда позволяет разгруппировать несколько параметров на конструктор и сам метод.

[egorinsk]

> И толком никакого профита не получить.

Профита три. 1) Функции группируются в классы по смыслу. Например, вместо function directoryCopy(), directoryRemove() и т.д. получаем простой и логичный класс Utils_Directory с методами copy(), remove(). 2) работает автозагрузка. 3) вместо глобальных всюду-видимых и конфликтующих переменных у нас приватные статические поля класса. Инкапсуляция.

Главное — уметь давать правильные названия и правильно группировать методы в классы.

[Владимир Чернышев]

Автозагрузка разве что. Группировка — неймпсейсы/префиксы. Приватные статические поля — более глубокий рефакторинг, да ещё небезопасный в общем случае.

[egorinsk]

Перечитал еще раз вот это вот:

> в месте вызова функции инстанцировать объект и вызывать метод. Кроме всего прочего это иногда позволяет разгруппировать несколько параметров на конструктор и сам метод

А нафига? В чем логика вместо makeMeGood($a, $b, $с) вызывать $goodMaker = new GoodMaker($a); $goodMaker->setSomeOption($b); $goodMaker->finallyMakeMeGood($c);? Получаем кучу мусорного кода в классе, получаем раскиданный по приложению код создания и использования объекта, и гораздо больше писанины.

Я понимаю, если этот $goodMaker потом раз 20 используется, но вы-то предлагаете заменить «вызов функции» на эту цепочку. Давайте еще абстрактную фабрику и стратегию добавим, что уж там.

[Владимир Чернышев]

Часто функция не используется в одиночку, например $good = makeMeGood($a, $b, $c); makeGoodBetter($good); Заменить на $good = new Good($a, $b, $c); $good->makeBetter(); имхо читаемей.

Answer 2

[belkamax05]

Еще, как вариант, разобраться в структуре Code Igniter. Там очень хорошо реализовано MVC и при он очень легкий для изучения. Его легко понять даже не зная PHP

Comments

[belkamax05]

при этом*

[Виталий Юшкевич]

на сайте российского комьюнити выложена достаточно подробная и понятная документация как по функциям самого фреймворка, так и логика работы самой модели MVC code-igniter.ru/user_guide/overview/appflow.html

[Александр Токмаков]

А я вот его так и не осилил :(

Answer 3

[Владимир Чернышев]

Это тоже MVC :)

<?php
// /user.php?<id>

function getUserNameById($id) {
  mysql_connect() or die("Can't connect");
  mysql_select_db('myapp_db') or die("Can't select");

  $result = mysql_query("SELECT name FROM users WHERE id = " . mysql_escape_string($id) . " LIMIT 1") or die("Can't query");
  $row = mysql_fetch_row($result) or die("Can't find");
  mysql_close();
  $name = $row[0];

  return $name;
}

public function showUser($id, $name) {
  echo "<html>Name of user with id = " . htmlspecialchars($id) . " is " . htmlspecialchars($name) . "</html>";
}

$user_id = empty($_GET['id']) ? $_GET['id'] : null;
$user_name = getUserNameById($user_id);
showUser($user_id, $user_name);

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

Так писать, конечно же не стоит (по крайней мере без особых причин), но понимать, что это тоже MVC, что MVC это не свойство ООП-фреймворков, и даже не свойство ООП, а свойство архитектуры приложения — нужно. И для того чтобы архитектура обладала этим свойством (использовала паттерн MVC) вовсе не нужно раскидывать компоненты приложения по куче разных объектов и/или файлов, использовать другие паттерны архитектуры и реализации, достаточно чтобы данные, их представление и управление ими были разделены логически.

Answer 4

[Сергей Протько]

MVC хорошо представлен в Django.
Model — бизнес логика, все что касается обработки и хранения данных
Controller — в джанго оно именуется темплейтами… по сути это та часть программы, которая подготавливает данные для скармливания представлению.
View — представление лишенное бизнес логики (идеально — просто представление)

Посмотрите на Yii, Symfony 2… и вперед.

Comments

[Сергей Протько]

Так же полезно изучить MVVM, Model-View-Presenter, Model-view-adapter…

[Vampiro]

Вы сейчас «провалитесь» в куче новых терминов.

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

MVC показывает где и как вы храните код, данные и прочее. Фактически, MVC это хранение данных-отдельно, Шаблонов отображения — отдельно, а кода — отдельно. Прямо в отдельных файлах. Всё.
Если вы в коде вставляете HTML-тег в переменную — капец, вы сделали шаг от MVC. Это очень просто. А вот шаблоны проектирования действительно требуют слома мозга и принципов «думания» над алгоритмами. Погуглите на тему «банда четырёх».

[rgen3]

Спасибо, сейчас посмотрю )

[Сергей]

в Django терминологии вы запутались) Модель там это модель (ORM etc), контроллер это «вьюшка» а представление это шаблоны

[Сергей Протько]

Упс, перепутал темплейты и вюшки… Спасибо что поправили.

Answer 5

[Анатолий]

Какая бы ни была тупая и до безвести простая статья, но она хорошо илюстрирует работу MVC sitear.ru/material/mvc-php

Comments

[Анатолий]

chtivo.webhost.ru/articles/mvc.php А вот посложней.

Answer 6

[SaleMind]

www.fluffycat.com/PHP-Design-Patterns/ паттерны на PHP + примеры использования

Answer 7

[AxisPod]

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

Comments

[Владимир Чернышев]

MVC паттерн. Пруф — martinfowler.com/eaaCatalog/modelViewController.html

Answer 8

[ainu]

>И еще один вопрос: какие аналоги модели mvc вы можете предложить?
HMVC

Answer 9

[TheHorse]

Короче, MVC и прочие альтернативы — частные случаи более общей парадигмы, которую лично я называю Layers.
Не парьтесь по поводу MVC. Просто разделяйте разные слои/части приложения. Делайте независимые модули. Декомпозируйте/композируйте.

Не стоит приплетать MVC или что-то похожее лишь потому, что это круто.

Comments

[dnclive]

+1000! Как раз готовлю статью на эту тему. Уровень структуризации должен соответствовать информационному объему, должен быть обоснован. MVC — у подхода есть своя ниша. Отсутствие архитектуры и одноразовый код — это плохо. Хотя и на это бывают свои причины…