MVC – проблема или решение PHP


Оглавление (нажмите, чтобы открыть):

MVC – проблема или решение? PHP

В предыдущем уроке мы дошли до следующей структуры:

  • Модель предметной области (или просто Модель) описана с помощью ORM (хотя это не обязательно, хранилище — вещь отдельная от модели).
  • Функция-обработчик обращается к модели для выполнения запрошенных операций и выводит необходимые данные в шаблон.
  • Шаблон описывает представление конкретной страницы и строится на основании данных переданных из функции-обработчика.

Описанная структура носит гордое имя MVC или Model-View-Controller (обычно добавляют приписку version 2, так как первая версия MVC используется для толстых клиентов, в которых все работает немного по-другому), где M — модель предметной области, C — наша функция обработчик (в других фреймворках могут быть другие сущности), а V — шаблон. MVC разделяет приложение минимум на три слоя и определяет то, как они могут взаимодействовать друг с другом. Это важно для создания модульных приложений, то есть таких, которые легко развивать и модифицировать. При этом никто не запрещает добавлять новые и дробить текущие слои, все это уже зависит от сложности самого приложения.

  • M — ядро приложения. В идеале — чистая бизнес-логика. M не знает ничего о других частях приложения и не может на них влиять.
  • C — использует M для выполнения запрашиваемых операций и отвечает за генерацию V.
  • V — получает данные от C и иногда от M, но такое не приветствуется. И уж точно V не должен знать ничего о базе данных. Кстати, этим грешат начинающие разработчики, которые выполняют SQL запросы прямо из шаблонов.

MVC является архитектурным шаблоном (или паттерном проектирования). Шаблон проектирования в разработке — повторяемая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста. В нашем случае контекст — обработка http-запросов.

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

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

MVC – проблема или решение? PHP

Принцип Модель-Представление-Контроллер ( Model-View-Controller, MVC ) был сформулирован еще в конце 70-х годов XX века. Это архитектура построения программного обеспечения, при которой данные независимы от методов, которые с ними работают.

Теоретически, грамотно построенная MVC-система должна позволять фронтэнд — и бэкэнд-разработчикам работать над одним проектом без необходимости работать над одними и теми же файлами одновременно.

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

MVC поощряет разработку модульных систем, позволяя быстро модифицировать проект, добавлять и удалять функционал.

В этой статье будут рассмотрены базовые принципы подхода MVC, дано определение этому понятию и разобраны небольшие примеры на PHP.

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

Понятие MVC

В название принципа входит три основополагающих компонента: модель ( Model ), представление ( View ) и контроллер ( Controller ).

Визуальное представление завершенного и корректного MVC-приложения выглядит так, как показано ниже:

Изображение демонстрирует прохождение одиночного потока данных через все компоненты и их взаимное отношение друг к другу.

Модель

Название «модель» обозначает хранилище данных, используемых во всей конструкции. Оно должно предоставлять доступ к данным для их просмотра и изменения. Модель является своего рода мостом между представлением и контроллером.

Одним из важных аспектов модели является то, что технически она «слепа» и не имеет представления о том, что происходит с данными, когда они проходят через представление или контроллер.

Модель не вызывает и не ожидает ответа от других компонентов, а просто обрабатывает данные в своем хранилище и готовит их к отправлению другим компонентам.

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

Зачастую наиболее сложной частью системы MVC является именно модель — связующее звено между контроллером и представлением.

Представление

Этот компонент отображает данные, полученные из модели, в определенном виде. Традиционно, в веб-приложениях использующих MVC, представление является набором HTML-файлов, которые и формируют облик выводимых данных.

Представление также определяет реакцию пользователя, который затем взаимодействует с контроллером. Простейшим примером этого может служить кнопка, сгенерированная представлением, по которой кликает пользователь, тем самым запуская взаимодействие с контроллером.

Среди веб-разработчиков, использующих MVC, существуют некоторые заблуждения относительно компонента представления.

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

Более того, описание представления как файла шаблона неверно. Однако, как заметил Tom Butler , это не ошибка какого-то одного человека, а совокупность заблуждений многих разработчиков, неверно усвоивших теорию MVC. А затем они передают свой опыт другим, что сами понимаете к чему ведет.

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

Также стоит заметить, что представление никогда не получает данные из контроллера. Как было замечено при обсуждении модели, прямой связи между представлением и контроллером, минуя модель, нет.

Контроллер

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

Источником, приводящим в движение контроллер, является пользователь; без взаимодействия с ним, существование контроллера не имеет смысла. Это единственная часть MVC, с которой напрямую имеет дело пользователь.

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

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

Контроллер активен только тогда, когда пользователь взаимодействует с представлением. Иными словами, пользователь, работая с представлением, по принципу триггера запускает контроллер.

Распространенной среди разработчиков ошибкой является присвоение контроллеру функций, которые должно иметь представление.

Это результат того, что некоторые разработчики считают представление просто шаблоном. В дополнение ко всему, ошибкой является придавать контроллеру функции, делающие его единственным ответственным за передачу и обработку данных от модели к представлению, в то время как в MVC эта ответственность должна распределяться между моделью и представлением.

MVC в PHP

Давайте напишем веб-приложение на PHP, которое будет использовать MVC.

Начнем с простейших примеров:

Для начала, мы создали несколько базовых классов для каждой части нашей реализации MVC.

Теперь настроим отношения между ними:

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

Представление хранит все функции, что сделано исключительно в демонстрационных целях.

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

Мы расширили наше приложение.

Отношения между нашими компонентами теперь выглядят так:

После запуска кода, кликните по ссылке, и вы сможете увидеть строку с измененными данными.

Заключение

Мы рассмотрели основы MVC и создали простейшее приложение на основе этой архитектуры, но впереди еще долгий путь, прежде чем мы получим желаемый результат.

Перевод статьи «The MVC Pattern and PHP, Part 1» был подготовлен дружной командой проекта Сайтостроение от А до Я.

Добро пожаловать! Это вторая часть цикла статей, касающегося использования MVC в PHP-приложениях, в которой мы обсудим некоторые вопросы, возникающие в связи выше обозначенной темой.

Если вы не читали первую статью из данного цикла, то настоятельно рекомендуется начать чтение именно с нее, чтобы полностью быть в курсе дела. Итак, начнем!

Перенаправление и URL-адреса

Хотя теоретически MVC должна работать независимо от языка программирования, подружить её с PHP может оказаться непросто.

Первая проблема касается перенаправления URL-адресов. Этот аспект не продумывался при создании схемы MVC, вследствие чего, этот вопрос стал вставать очень остро.

Какие возможности мы имеем для решения проблемы переадресации? Первое, что можно попытаться сделать, это заранее записать все URL-адреса вашего сайта в специальное хранилище, вместе с информацией о том, какие модель, представление и контроллер будут загружены для каждой страницы или её части.

В этом случае, система берет запрошенный пользователем URL-адрес и загружает компоненты, привязанные к данной странице.

Этот способ подходит, если вы создаете, к примеру, сайт-портфолио со статическими адресами (но не динамическими):

Теперь, наши URL-адреса будут выглядеть так:

Приведенный выше пример MVC-системы , загружает модель, представление и контроллер, указанные для запрошенной страницы. Если параметр имеет значение «about», то будет отображена страница About . Если параметр имеет значение «portfolio», то, соответственно, будет загружена страница Portfolio .

Как мы можем видеть, даже у этого простого примера статического перенаправления, есть недостатки. Один из самых очевидных из них, это проблемы с масштабируемостью при расширении сайта, так как все ссылки жестко «зашиты» в массив.

Другим способом решения нашей задачи является создание классов модели, представления и контроллера, позволив им формировать значения параметров URL-адреса.

В примере со статической переадресацией, мы просто вытаскивали значения из массива и возвращали их в качестве параметров при загрузке страниц. Удаление данного массива позволит нам реализовать динамическую переадресацию.

Несмотря на то, что мы вынимаем значения из заранее сформированного массива, отношения между классами уже настроены.

При наличии фиксированного массива, мы не можем динамически переназначать параметры. Но зачем нам вообще может понадобиться это делать?


Ответ прост : в таком случае нам не нужно будет заполнять вручную массив всеми возможными ссылками, имеющимися на сайте.

Мы можем создавать страницы или их части с помощью модели, представления и контроллера.

Теперь наши ссылки будут выглядеть так:

Параметр «action» говорит системе, какую функцию контроллера нужно запустить. Важно помнить, что когда эта функция передает данные в модель, то вместе с ними передается информация о том, какое представление и действие нужно загрузить.

Это может быть, опять же, значение переменной «action», или отдельные данные, либо данные, сохраненные контроллером. Никогда не позволяйте контроллеру загружать или напрямую передавать данные представлению. Эти два компонента должны взаимодействовать только через модель и действия пользователя.

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

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

Добавление фронт-контроллера позволит вашей системе динамически загружать секции, в зависимости от того, что нужно показать. Человек по имени Alejandro Gervasio написал потрясающую статью в двух частях о шаблоне фронт-контроллера (the Front Controller pattern), которая затрагивает вопросы использования фронт-контроллера в MVC-приложении.

DRY (Don’t Repeat Yourself — принцип программирования «не повторяй сам себя») и шаблоны

Одним из аргументов «за» использование MVC, является общее улучшение организации вашего проекта, насколько это возможно.

Также, это позволяет свести к минимуму возможное повторное использование ранее написанного кода. Любой разработчик согласится, что худшее, что можно обнаружить в любом проекте, это повторение кода. Техника и целая философия, призванная сохранить читаемость кода и позволить повторно использовать компоненты, известна под названием DRY (Don’t Repeat Yourself) — «Не повторяй сам себя».

Принцип DRY говорит, что «каждый кусочек знания должен иметь единственное, однозначное и авторитетное представление внутри системы». Цель DRY состоит в том, чтобы дать разработчику все возможности для создания максимально динамичных и оптимизированных систем.

DRY также подразумевает, что если вам необходимо использовать один и тот же кусок кода в разных местах, то необходимо оформить его в виде метода и вызывать его при необходимости. Это позволяет оптимизировать работу системы и предоставляет возможность кэширования внутри системы для повышения общей производительности.

Корректная реализация этого принципа также означает, что изменение какого-либо элемента не влияет на работу других, не связанных с ним элементов, что делает DRY очень важным при разработке MVC-приложений.

Шаблоны

Слово «шаблон» может вызвать некоторые вопрос при попытке понимания его сути для тех, кто ранее сталкивался с веб-фреймворками на основе MVC, потому как большинство людей подразумевает под этим только представление.

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

Затем, представление выбирает шаблон и передает в него полученные данные. Теперь, все готово для отображения с использованием блочной разметки, или с использованием операторов PHP : echo, print и подобных.

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

Ниже дан простой пример загрузки шаблона и передачи в него данных:

В дополнение к этому, шаблон пропускается через модель. Это позволяет динамически выбирать шаблон в зависимости от назначения той или иной модели.

Этот метод позволяет эффективно и беспрепятственно расширять MVC-систему, разделив разработку интерфейсной и внутренней частей приложения, что как раз и является истинной целью MVC-подхода.

Заключение

Схема MVC, только появившись, создала почву для бесконечных дебатов на тему интерпретации и реализации этой концепции в конкретных приложениях.

Споры становятся все более интенсивными по мере роста популярности использования PHP для создания веб-приложений. Это хороший знак, который указывает на подключение все большего количества разработчиков, которые желают усовершенствовать подход в программировании на PHP.

Использование MVC является очень предпочтительным, так как поощряет разделение разработки на независимые ветви, иначе говоря, позволяет отделить разработку фронт-энда от разработки бэк-энда.

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

Перевод статьи «The MVC Pattern and PHP, Part 2» был подготовлен дружной командой проекта Сайтостроение от А до Я.

ASP.NET MVC или PHP YII. Сравнение производительности

Я член freelance команды AdvanceDev и к нам очень часто обращаются заказчики с просьбой разработать сайт или срм, именно на php. Если мы предлагаем разработку на asp.net, то в ответ слышим множество необоснованных аргументов против asp.net и в пользу php.

В данной статье я хочу разобраться с наиболее часто приводимым аргументами против asp.net. Стоит отметить, что тут и везде, под asp.net подразумевается asp.net mvc, а не asp.net web-forms. Это две разные технологии, как груша и яблоко, путать их между собой не стоит.

Я ни в коем случае не хочу умалить достоинства php, моя цель — доказать, что asp.net не хуже.

И так, самые распространенные «причины» по которым заказчики не хотят иметь сайт или систему на asp.net

Asp.net устарел, а php это передовые технологии

Это совершенно не так. PHP был разработан в 1994 году и предназначался для разработки небольших сайтов. PHP — Personal Home Page, что в переводе означает Персональная Веб Страница. С тех пор php сильно вырос, последняя версия PHP 5.6 была выпущена летом 2014 года.

ASP.NET MVC был разработан в 2007 году и выпущен в открытое использование в 2009 году. Последняя версия asp.net mvc 5.2.2 вышла летом 2014 года.

Из сказанного выше можно сделать вывод, что asp.net mvc это более современная технология, тем не менее, обе технологии поддерживаются и развиваются с одинаковым темпом.

Для php есть множество программистов, которые смогут взять сайт в любой стадии и продолжить над ним работу. В то время как asp.net программистов очень мало

Для решения этого вопроса нужно четко определить, кто входит в разряд «программистов». Если asp.net и php изобразить картинкой, то результат будет примерно такой:

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

Базовые знания php освоить проще, чем asp.net, поэтому все, кто хоть немного знают php, рекламируют себя как «php программист». Когда же доходит до разработки серьезных вэб-сайтов или вэб-систем, такие программисты проваливают сроки, сливаются и пропадают со связи.

К нам очень часто обращаются заказчики с просьбой «доработать сайт на php, так как его создатель не может сделать эту функцию» или «переработать сайт на php, так как он работает очень медленно и с ошибками, а его создатель получил деньги и пропал со связи». Но еще ни разу не было случая, когда к нам обратились с подобной просьбой для asp.net сайта.

На самом деле, программистов высокого уровня на php и на asp.net примерно одинаково. Очень часто квалифицированные программисты умеют программировать и на php, и на asp.net.

Любой программист, у которого есть пару лет опыта работы и несколько реализованных больших проектов и на php, и на asp.net mvc скажет, что в php не хватает множества полезных функций, которые упрощают и ускоряют разработку сайта или веб-приложения.

Для работы asp.net сайта нужен дорогой сервер, на обычном хостинге сайт работать не будет

Еще одно заблуждение. Цены на хостинг для php и asp.net не отличаются. Вот пример: http://www.1gb.ru/, даже самый минимальный тарифный план «Стандарт» уже поддерживает asp.net, а всего за 274р в месяц можно получить и MS-Sql Server, любой необходимой версии.

Для большого сайта, будь то php или asp.net придется арендовать виртуальный или реальный сервер, цены на сервера не отличаются.

Для php предпочтительней использовать операционную систему Linux, она бесплатна. В случае необходимости, php сайт можно с легкостью перенести на Windows сервер.

Windows это родная и предпочтительная операционная система для asp.net. Однако asp.net так же может работать и под Linux, с некоторыми ограничениями.

Стоимость покупки пожизненной лицензии:

  • Windows 2008 R2 — от $250
  • Windows 2012 R2 — от $500

Из-за того, что в php не хватает множества возможностей, которые есть в asp.net, разработка на php выходит дольше, а следовательно дороже, чем на asp.net. Из нашей практики, цена одного и того же проекта на php и asp.net отличается в 1,5-2 раза.

Небольшой расчет по проекту:

ASP.NET MVC + Windows + MS-Sql Server

  • Разработка системы — $2000
  • Операционная система — $500
  • MS-Sql Server — бесплатная версия
  • Итого $2500

PHP YII + Linux + MySql Server

  • Разработка системы — $3000
  • Операционная система — $0
  • MySql Server — бесплатная версия
  • Итого $3000

Как видим, разработка одной и той же системы на php обходится дороже, чем на asp.net, даже с учетом покупки лицензии Windows. Если вас не устраивает бесплатная версия MS-Sql Server, то всегда можно использовать MySql Server. MySql отлично работает под Windows.

Если же принять во внимание не только деньги, а еще сроки разработки и скорость работы приложения, то asp.net будет иметь еще более явное преимущество над php.

Мастер Йода рекомендует:  22 августа 2020 года Яндекс презентует новый поиск

Сайт написанный на asp.net работает медленней чем php вариант и начинает еще больше тормозить с приростом количества пользователей

Наверное, самая большая причина, из-за которой заказчики «боятся» asp.net. Устаревший asp.net действительно тормозит и потребляет много ресурсов. Но asp.net и asp.net mvc это разные технологии, путать их между собой нельзя! Очень часто, php программисты не имеют никакого представления о том, что такое asp.net mvc и как эта технология работает, судят только по названию и утверждают, что asp.net mvc устарел и уступает php по всем параметрам.

Я провел тестирование производительности php и asp.net mvc под Linux и Windows. Для тестирования был создан небольшой сайт, в котором есть набор продуктов, набор заказчиков, набор заказов и набор позиций заказа. Всего четыре сценария тестирования.

На всех диаграммах, справа указано время в секундах, снизу указано кол-во пользователей сайта. Для удобства чтения я сократил некоторые название:

  • win – windows
  • asp.net – asp.net mvc
  • ms-sql – ms-sql server
  • mysql – mysql server

1. Импорт из текстового файла

Есть файл в котором находится список заказчиков. Необходимо прочитать данные из файла, отсортировать по алфавиту, найти кол-во гласных букв в имени заказчика и вывести результат пользователю.

Как видно из результатов тестирования, в данной задаче asp.net под windows несущественно уступает php под linux при небольшом кол-во пользователей и значительно опережает конкурента при большом количестве пользователей.

Несравнимо плохой результат показывают php под windows и asp.net под linux.


2. Экспорт в excel из базы данных

Необходимо выбрать всех заказчиков из базы, отсортировать по алфавиту, сохранить в excel файл и отдать пользователю ссылку для скачивания файла.

Во всех тестах побеждает asp.net mvc под windows в связке с ms-sql server, для выполнения той же задачи php под linux + mysql потребовалось более чем в два раза больше времени.

Почти такой же результат показала связка asp.net mvc под windows + mysql, тогда как asp.net под linux + mysql опережает php, но не на много. Связка php под windows + mysql еще раз очень сильно отстает.

3. Выборка и отображение товаров из базы

Поиск товаров по категории и части названия. Результат отобразить пользователю в виде таблицы.

И тут asp.net опережает php в любой связке. Стоит ометить, что mysql кэширует результат запроса и не выполняет одинаковый запрос несколько раз, если не было изменений в базе. Из-за этого mysql опережает ms-sql в данном тесте. Если вручную сделать кэширование для ms-sql, то результаты будут примерно одинаковыми.

4. Оформление заказа

Выбрать случайного клиента. Создать для него заказ. Набросать в заказ десять случайных товаров. Сохранить данные и вывести пользователю на экран информацию о покупателе и список товаров.

В последнем тесте, связка asp.net mvc под windows + ms-sql с большим отрывом опережает все остальные варианты. Почти в два раза отстает php под linux + mysql, asp.net + mysql под windows и linux показывает неплохой результат, а php под windows и тут очень сильно отстает.

Средняя производительность по четырем тестам

Не трудно заметить, asp.net + ms-sql опережает php + mysql при любом количестве пользователей и чем больше пользователей, тем сильнее этот отрыв.

asp.net + mysql показывает примерно такой же результат как и php + mysql, но все же вырывается вперед,
asp.net + mysql под linux немного отстает от windows версии,
а php под windows работает так медленно, что его нет смысла даже показывать.

Все тесты проводились на одном и том же компьютере. Во время тестирования не была запущена ни одна лишняя программа. Каждый тест был запущен четыре раза и взят средний результат.

Тестирование проводилось под:

  • ASP.NET MVC 4, .NET 4.5
  • PHP 5.6 YII2
  • Windows 8, IIS8, MS-SQL Server 2012 Express, MySql 5.5
  • Ubuntu 14.10, Apache2, MySql 5.5
  • Ubuntu 14.10, Nginx + fastcgi-mono-server4, MySql 5.5
  • CPU: AMD Phenom II 965 x4
  • RAM: 4gb RAM
  • HDD: WD 1T

И в заключении хочу привести несколько примеров успешного использования asp.net mvc в огромных проектах.

  1. http://stackoverflow.com/ — форум для программистов и не только. Около миллиона посетителей в день.
  2. http://dearsystems.com/inventory-software/ — популярная в Австралии и США СРМ система складского учета.
  3. http://www.asp.net/ — сайт по asp.net.
  4. http://live.com/ — популярный почтовый сервер и не только.
  5. http://www.documentoved.ru/ — Документовед, онлайн-сервис оформления документов.

Тут можно посмотреть статистику развития и популярность asp.net mvc
https://www.similartech.com/technologies/asp-net

Что за бред я только что прочитал? Автор, ты действительно веришь в то, что написал?

«Старый ASP.NET медленее PHP о_О А MVC это же совсем другое дело, он намного быстрее» а ничего, что старый ASP.NET и ASP.NET MVC отличаются в этом плане совсем незначительно и показывают на простейших операциях примерно одинаковые результаты?

Разработка сайта на ASP.NET дешевле чем PHP? Разработка сайта с нуля на ASP.NET MVC выходит дороже, чем на ASP.NET WebForms и гораздо дороже, чем ПХП+CMS(которых под него огромное количество).

Правда в том, что 90% клиентов достаточно сайта на WordPress (именно на нем, а не на PHP). А вот сложные веб-приложения действительно лучше разрабатывать на ASP.NET MVC или WebForms в зависимости от того, что требуется.

Арам, большое спасибо за авторитетное мнение без каких-либо оснований и фактов. Верить или не верить можно в что-то не проверенное, а я всего лишь излагаю информацию, основываясь на факты. Если сравнивать простейшие операции, почему тогда не написать сайт в виде c++ cgi, ведь будет еще быстрее? Очевидно, что речь идет о больших системах. На asp.net webforms можно написать быстрый сайт, но придется уходить от концепции и делать гибрид между webforms & mvc. Если брать во внимание сайты-визитки и блоги, то тут php будет выгодней. Но любой, мало-мальски толковый проект, с небольшой порцией сложной логики ставит эти cms в тупик. У меня есть больше дюжины заказчиков, которые «испугались» моей цены и обратились к «php умельцам». Получили сайт на какой-то cms (WordPress, OpenCart, Joomla) и были довольны, но не долго. Через месяц или два, в голову приходит «феноменальная» идея, которую php умелец не может реализовать в силу ограничений cms, либо это будет очень дорого. В результате заказчик выкидывает php сайт и обращается ко мне. 90% чьих клиентов? 90% моих клиентов заказывают сложную crm систему ценой от 3000$, поэтому не стоит кричать во все стороны, что WordPress спасет web-мир.

Const, окей, давайте поговорим о фактах. В вашей статье я увидел результаты тестов с простейшими операциями. Но на их основании Вы делаете выводы и о сложных системах.

Я сам часто доделываю эти недосайты от недопрограммистов (которые научились устаналивать CMS и плагины и решили, что уже умеют делать сайты) и я не люблю PHP (хотя при достаточном уровне можно и на нем написать что угодно).

Скорость работы приложения не всегда является самым важным критерием. Например, если говорить о скорости работы, то крупные распиаренные ORM (EF, NHiberbnate) заметно уступают прямому доступу к БД, но это не мешает их использовать в том же ASP.NET MVC. Вы, кстати, что используете у себя?

Теперь о том, что я назвал бредом:

Статья о сравнении производительности ASP.NET MVC и PHP YII, а в итоге сравниваете просто ASP.NET и PHP.

ASP.NET WebForms никогда не был медленее PHP. Как минимум 10 лет назад, когда я начинал с ним работать, он был быстрее, удобнее и надежнее.

Скорость работы приложения ASP.NET MVC и ASP.NET WebForms при равном уровне профессионализма разработчиков почти одинаковая, потому что они обе используют один и тот же стэк технологий. Естественно, если Вы не умеете работать с WebForms, то ваше приложение будет работать медленно и жрать много ресурсов. При этом скорость разработки на WebForms как правило выше (исключения, естественно бывают).

90% клиентов, которым нужны веб-сайты. Хотеть они могут много чего, но на самом деле им нужны сайты-визитки со стандартными плагинами и разным дизайном. И WordPress лидер в этой области. Раз уж мы говорим о достаточно узком круге клиентов, которым нужна разработка CRM (и по каким-то причинам уже готовые продукты их не устраивают), то стоило об этом написать в заголовке статьи. И да, о том, что сложные проекты лучше писать на ASP.NET MVC я тоже написал.

Арам, спасибо за адекватный ответ. Я постарался сделать более-менее большую базу данных и не совсем уж примитивные сценарии тестирования. К сожалению, у меня нет возможности написать две идентичные crm на asp.net mvc и php yii, чтобы сравнить их производительность. Если у Вас есть такая возможность, то буду рад за предоставленную информацию. Тут нигде не написано, что скорость – самый важный фактор, что asp.net mvc хуже/лучше php или что-то в этом роде. Я собрал аргументы, которые приводят заказчики в пользу php yii и против asp.net mvc, затем опроверг их. Все.

  1. В самом начале я написал, что под asp.net подразумеваю именно asp.net mvc, php yii был взят из-за того, что очень много заказчиков убеждены, что это вершина возможностей и использовать нужно именно yii.
  2. Сам по себе asp.net WebForms не медленней. Проблема в том, что сама концепция оказалась очень ресурсоемкой и большинство программистов все спихивали на framework, в результате чего, сайт жутко тормозил, мне пришлось перерабатывать не один такой сайт. На asp.net WebForms можно создать хороший сайт, даже на чистом asp можно. Но на эту тему нужно писать отдельную статью.
  3. Согласен. Но как я уже писал выше, чтобы избавиться от пожЕрательства ресурсов, нужно делать гибрид с mvc, что выходит совсем не быстрее.
  4. Опять согласен. Но статья именно про разработку сайта или приложения с нуля. В самом начале я написал: «. обращаются заказчики с просьбой разработать сайт. «, именно разработать сайт, а не создать клон WordPress. Возможно, это не очевидно, мой косяк.

Статью каждый понимает с учетом своего опыта работы в YII/ ASP NET MVC Когда-то часто сталкивался с подобными вопросами, и перерывал весь инет в поисках статьи, где в одном месте было бы изложены за и против + с «фактами», спасибо. А за статистику автору отдельное спасибо!

От себя же сказу, часто сталкиваюсь с тем что надо с C# WPF (использую паттерн MVVM), т.е. десктопного приложения, перенести функционал в web. И здесь уже вопросов не стоит на чем писать, (silverlight не рассматриваем). Поэтому выбор падает только на ASP.NET MVC.

Арам, человек потратил время, написал интересную статью, а вы в лоб «Что за бред я только что прочитал?». Вы напишите свою статью, чтобы так говорить. Но не это главное, ведь есть еще те, кто ничего не понимают еще, и кому подобная статья очень важна — и возможно стоят перед выбором ASP.NET MVC/YII, но читают такой отзыв, и закрадывается, что статья бредовая, хотя на деле (и по «фактам») наоборот.

Ollon, не знаю вашего имени, но спасибо за хороший отзыв, рад что статья понравилась.

На самом деле, ASP.NET (и MVC и WF) всегда будет быстрее, чем php по той причине, что, во-первых, это компилируемый код (т.е. программа выполняется процессором, а не интерпретируется), во вторых, .NET — это JIT-компиляция, компиляция «на лету» (при первом запуске программа компилируется из IL в код, понятный данному процессору, при последующих запусках она уже работает быстрее и оптимальнее для данного процессора). Примерно то же самое можно сказать о Java VM. А PHP код постоянно интерпретируется при каждом обращении. Даже всем известный фэйсбук, написанный когда-то на PHP, сейчас имеет «ядро», написанное на Си, а PHP в нём используется только как шаблонизатор.

Mike, полностью согласен. Но заказчикам, которые прочитали, что Yii, CakePhp, OpenCart, Joomla, WordPress и иже с ними, такие хорошие, все умеют, все делают и при этом совершенно бесплатно, объяснить, что такое JIT и компиляция невозможно.

Зачем спорить, что лучше, а что хуже. Лучше выучить оба языка и не париться, все же заказчик определяет на чем программировать а не мы программисты. Мне лично легче на ASP.NET MVC, но приходиться писать и на PHP.

Анвар, как раз для того чтобы реже писать на PHP и чаще на ASP.NET, и была написана эта статья.

Добрый день! Если продолжите исследования в этой области, очень много людей будет благодарно. По тому что надоело делать два варианта и потом слышать от заказчиков увидевших разницу в производительности:». удивительно, а нам же говорили что PHP быстрее».

SunnyRitter, добрый день!

К сожалению, сейчас нет возможности заниматься исследованием asp.net и php, так как я работаю в http://www.starcounter.com/. Starcounter позволяет разрабатывать web системы нового поколения. Ознакомиться с технологией можно тут http://starcounter.io/. Если будут какие-то вопросы, можно задавать их лично мне.

Оч. понравился aps.net mvc с точки девелопера. Приятная ide (vs) + много фишечек от mvc ето круто.

Хочется узнать о хостингах asp.net mvc которие ви считаете хрошими по цена\качество. Например хостинг для небольшого блога на aps.net mvc5\6 и хостинг например для большого сайта, допустим с базой фильмов, актеров итд итп на 1м фильмов.

Что би ви посоветували или где искать, так как я только учу aps.net, очень нравится, и хочеться би узнать где би захостить чтото) не оч. дорого

Dimon, привет.

  • Я пользуюсь услугами хостинга http://www.1gb.ru/, мой сайт тут размещен.
  • И еще арендую сервер в Германии: https://www.hetzner.de.

Автор пишет: «Устаревший asp.net действительно тормозит и потребляет много ресурсов. Но asp.net и asp.net mvc это разные технологии, путать их между собой нельзя!»

Здесь я с ним не согласен ASP без приставки Net, да устаревший, тормознутый (т.к. интерпритируемый) и потребляет много ресурсов. ASP.Net это новая технология. ASP.Net MVC это фреймворк который включен в ASP.Net. ASP.Net это технология, ASP.Net MVC это подход для использования ASP.Net. Всетаки в статье лучше поправить где ASP, а где ASP.Net.

По поводу стоимости разработки полностью солидарен с автором. В Интернете есть статьи где аргументом в пользу использования PHP выдвигают, то что его используют Google, Facebook и другие гиганты, да используют, но то сколько зелёных они потратилита на то чтоб заставить «бесплатный» PHP работать быстрее (за счет вынесения логики на C) упоминуть забыли.

Был у меня как-то довольно интересных опыт: Требовался сайт для автоматизации бизнес процеса в компании для её решения был необходим еще один программист, на чём писать был в замешательстве мог на ASP.Net(к чему и склонялся) и на PHP, ранее эту задачу дали PHP программисту, по неизвестным причинам он её не смог сделать, бюджет начальство не интересовал, но в рамках разумного. Начали искать программиста по обоим направлениям, PHP программисты приходили говорили что без WordPress или Joomla писать не будут, все были с порфолио с десатками сайтов, т.е. не дураки. В конечном итоге взяли .Net программиста без опыта и сделали работу за 2 месяца на ASP.net WebForms. Позже начальство нам поставило задачу заставить работать оборудвание по командам с сайта, и радости моей не было предела т.к. я смутно представлял как это реализовать на PHP и реально ли это. ASP.Net работает с Windows, оборудование работает с Windows. Без танцев с бубном сделали и это. Я это к тому что все таки надо подбирать инструмент под задачу. И что людей знающих PHP на довольно приличном уровне не так много как кажется.

Michael, согласен с вами.

asp.net mvc, как и asp.net web forms, это технологии разработки сайтов на asp.net.

Говоря asp.net, я подразумеваю asp.net web forms. При появлении asp.net была только одна технология — web forms, mvc — появился позднее. Согласен, что это не очень корректно.

Автор во многом все же прав. На ASP.NET MVC также быстрее и легче создаются сложные мультимедийные и графические web-ресурсы. В этом пришлось недавно убедиться на примере популярного за рубежом SDK LEADTOOLS (https://www.leadtools.com/).

Здравствуйте, набрел на вашу статью, изучая и сравнивая PHP и ASP.NET MVC. Как Вы считаете, есть ли в ближайшем будущем перспектива у ASP.NET MVC стать часто используемым языком в вебе, как php, при разработки Не корпоративных проектов, а любого вида сайтов, CMSок и тд? Смотрел на вакансии — чистых asp.net mvc веб-разработчиков очень мало требуется в Москве, даже front-end на порядок больше. Хочу развиваться как веб-разработчик, приоритет отдаю asp.net, тк знаю преимущества среды разработки и сервера MSSQL. Хотелось бы понять будет ли перспектива найти работу на asp.net в разработке всевозможных CMS, интеренет-магазинов (все что в основном написано сейчас на php), а не корпоративных решений?

puga1chev, здравствуйте.

В России PHP имеет такую большую популярность из-за видимой бесплатности. Если вы еще не знаете, что ASP.NET 6 (vNext) тоже бесплатный и с открытым кодом, то советую почитать. Уже выпущен Release Candidate, есть поддержка Windows, Linux, OSX. Поэтому, я не думаю, а знаю, что популярность ASP.NET будет расти и расширяться.

В любом случае, я считаю, что любой уважающий себя разработчик, должен ориентироваться именно на корпоративные решения, а не на болото из множества бесплатных CMS.

Const, рад был это услышать.

Является ли MVC единственным способом писать PHP?

Огромное количество фреймворков, доступных для PHP, теперь использует MVC. Даже ASP.net имеет свой собственный MVC-модуль.


Я вижу привлекательность MVC, я действительно могу и часто использую его. Единственный недостаток, который я вижу, заключается в том, что вы должны запустить всю систему для выполнения запроса страницы. В зависимости от вашей задачи это может быть немного расточительным.

Так что вопрос. В профессиональной среде это единственный способ использовать PHP в наши дни или другие методы проектирования, которые имеют альтернативные преимущества?

Мне не нравится, когда кто-нибудь говорит мне, как писать код. Если я хочу использовать MVC, я, если найду лучший способ решить конкретную задачу, я буду использовать ее. Мне не нравится, когда люди превращают MVC в религию. Я также думаю, что многие php-кодеры неправильно понимают концепцию MVC и думают, что используют шаблон MVC, когда на самом деле большую часть времени не используют 100% -ный чистый MVC. По правде говоря, нелегко и не очень эффективно писать веб-сайт, который является 100% MVC и написан на php.

Большинство людей испытывают наибольшие трудности в «V» части MVC. «М» легко. Это ваши данные. Если вы храните свои данные в базе данных и имеете класс доступа к базе данных, это ваша «M» часть, вы хорошо с «M»,

Теперь контроллер: когда пользователь нажимает на любую ссылку вашей страницы, ваш php-код должен получить данные из «M» (базы данных), подготовить его, применить некоторую логику, например добавить персонализацию для входа в систему, добавив ссылку «пожалуйста, войдите» если пользователь не зарегистрировал его и т. д. Это ваша часть «C».

Проблема, с которой сталкивается большинство людей, заключается в разделении «V» View с «C» (контроллер). Это непросто и не самый эффективный способ кодирования в php. Во многих случаях часть контроллера должна уже генерировать некоторый html, поэтому вы размываете линию между контроллером и представлением.

Если вы хотите остаться чистым MVC, вы должны убедиться, что ваш контроллер вернет чистые данные, тогда класс View возьмет некоторый шаблон, подключит ваши данные и вернет HTML. Здесь проблема кроется в php. Нет простого и эффективного способа создания шаблонов, где шаблон просто берет чистые данные как входные данные и возвращает html. Если бы был простой способ, тогда не было бы причин, по которым люди могли бы придумать еще одну новую библиотеку шаблонов. Причина, по которой так много библиотек шаблонов для php, состоит в том, что всегда есть программисты, которые недовольны ЛЮБОЙ из существующих и продолжают пытаться изобрести свои собственные, лучшие.

Единственной чистой библиотекой шаблонов, на мой взгляд, является XSLT, который полностью поддерживается php, он поставляется с php, он работает, это мощный, отличный механизм шаблонов, тем не менее, это стандартный, независимый от платформы язык. После изучения XSLT вы можете использовать его на любом другом языке программирования, таком как Java. Однако у него есть одна крошечная проблема. Он требует, чтобы входные данные были XML. Конечно, вы можете создать отличный, 100% действительный XML в php, также используя библиотеку DOM, которая также является частью php. Проблема в том, что она будет медленной. Вы будете выполнять двойную работу: сначала создайте XML из своего массива данных, а затем преобразуйте этот XML в HTML с помощью своего XSL-шаблона. Вот почему подход XSLT в качестве шаблонизатора никогда не снимался в php.

Теперь вы ушли с другими параметрами для анализа шаблонов, как правило, на основе регулярных выражений. Вы видите, как это всегда усложняется, когда мы попадаем в «V» часть MVC?

«M» легко, «C» – это некоторый тип чистого php-кода, будь то ООП или процедурный код, не имеет значения. Это «взгляд», который является сложным.

Поэтому мой совет – не беспокойтесь о прилипании к чистому MVC. Это нормально для контроллера, чтобы выплевывать куски html здесь и там.

Ну, есть много других подходов.

MVC просто популярен, потому что он подходит для большинства ситуаций (или, лучше сказать, может использоваться в большинстве ситуаций) и зарекомендовал себя как де-факто стандарт.

Можно сказать, что каждый шаблон программирования / дизайна – или более конкретная архитектура – зависит от некоторой классификации.

Это часто (разумеется, их можно разделить дальше):

Пользовательский интерфейс (красивые изображения, формы и т. Д.)

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

База данных – объяснение себя

Инфраструктура (очень простые вещи, такие как жесткий диск, серверные системы, сеть и т. Д.)

Мастер Йода рекомендует:  Выравнивание по вертикали c помощью CSS

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

Mvc является одним из них. Но вот некоторые примеры других:

Является ли MVC-ARS предпочтительным для классического MVC для предотвращения перегрузки?

Концепция MVC для чайников

Концепция MVC (Model-View-Controller: модель-вид-контроллер) очень часто упоминается в мире веб программирования в последние годы. Каждый, кто хоть как-то связан с разработкой веб приложений, так или иначе сталкивался с данным акронимом. Сегодня мы разберёмся, что такое — концепция MVC, и почему она стала популярной.

Древнейшая история

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

Впервые она была описана в 1979 году, конечно же, для другого окружения. Тогда не существовало концепции веб приложения. Tim Berners Lee (Тим Бернерс Ли) посеял семена World Wide Web (WWW) в начале девяностых и навсегда изменил мир. Шаблон, который мы используем сегодня, является адаптацией оригинального шаблона к веб разработке.

Бешеная популярность данной структуры в веб приложениях сложилась благодаря её включению в две среды разработки, которые стали очень популярными: Struts и Ruby on Rails. Эти две среды разработки наметили пути развития для сотен рабочих сред, созданных позже.

MVC для веб приложений

Идея, которая лежит в основе конструкционного шаблона MVC, очень проста: нужно чётко разделять ответственность за различное функционирование в наших приложениях:

Приложение разделяется на три основных компонента, каждый из которых отвечает за различные задачи. Давайте подробно разберём компоненты на примере.

Контроллер (Controller)

Контроллер управляет запросами пользователя (получаемые в виде запросов HTTP GET или POST, когда пользователь нажимает на элементы интерфейса для выполнения различных действий). Его основная функция — вызывать и координировать действие необходимых ресурсов и объектов, нужных для выполнения действий, задаваемых пользователем. Обычно контроллер вызывает соответствующую модель для задачи и выбирает подходящий вид.

Модель (Model)

Модель — это данные и правила, которые используются для работы с данными, которые представляют концепцию управления приложением. В любом приложении вся структура моделируется как данные, которые обрабатываются определённым образом. Что такое пользователь для приложения — сообщение или книга? Только данные, которые должны быть обработаны в соответствии с правилами (дата не может указывать в будущее, e-mail должен быть в определённом формате, имя не может быть длиннее Х символов, и так далее).

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

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

Вид (View)

Вид обеспечивает различные способы представления данных, которые получены из модели. Он может быть шаблоном, который заполняется данными. Может быть несколько различных видов, и контроллер выбирает, какой подходит наилучшим образом для текущей ситуации.

Веб приложение обычно состоит из набора контроллеров, моделей и видов. Контроллер может быть устроен как основной, который получает все запросы и вызывает другие контроллеры для выполнения действий в зависимости от ситуации.

Разберём пример

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

У нас есть определённый контроллер для обработки всех действий, связанных с книгами (просматривать, редактировать, создавать и так далее). Давайте назовем его books_controller.php в нашем примере. Также нам нужна модель, например, book_model.php, которая обрабатывает данные и логику, связанные с позицией в магазине. В заключение, нам нужно несколько видов для представления данных, например, список книг, страница для редактирования и так далее.

Следующий рисунок показывает, как обрабатывается запрос пользователя для просмотра списка книг по теме фэнтези:

Контроллер (books_controller.php) получает запрос пользователя [1] (запрос HTTP GET или POST). Мы можем организовать центральный контроллер, например, index.php, который получает запрос и вызывает books_controller.php.

Контроллер проверяет запрос и параметры, а затем вызывает модель(book_model.php), запрашивая у неё список доступных книг по теме фэнтези [2].

Модель получает данные из базы (или из другого источника, в котором хранится информация) [3], применяет фильтры и необходимую логику, а затем возвращает данные, которые представляют список книг [4].

Контроллер использует подходящий вид [5] для представления данных пользователю [6-7]. Если запрос приходит с мобильного телефона, используется вид для мобильного телефона; если пользователь использует определённое оформление интерфейса, то выбирается соответствующий вид, и так далее.

В чем преимущества?

Самое очевидное преимущество, которое мы получаем от использования концепции MVC — это чёткое разделение логики представления (интерфейса пользователя) и логики приложения.

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

Помимо изолирования видов от логики приложения, концепция MVC существенно уменьшает сложность больших приложений. Код получается гораздо более структурированным, и, тем самым, облегчается поддержка, тестирование и повторное использование решений.

А зачем использовать рабочую среду?

Когда вы используете рабочую среду, базовая структура MVC уже подготовлена, и вам остаётся только расширить структуру, размещая ваши файлы в соответствующих директориях для соответствия шаблону MVC. Кроме того, у вас будет набор функций, которые уже написаны и хорошо протестированы.

Рассмотрим cakePHP в качестве примера рабочей среды MVC. После установки у вас будет три основных директории:

Папка app является местом размещения ваших файлов. Это место для разработки вашей части приложения.

В папке cake размещаются файлы cakePHP (функциональность рабочей среды).

Папка vendors служит для хранения библиотек PHP сторонних разработчиков.

Ваше рабочее пространство (директория app) имеет следующую структуру:

Вам нужно размещать ваши контроллеры в директории controllers, модели в директории models и виды в директории views!

Как только вы начнёте использовать рабочую среду, то сразу станет ясно, где размещается практически любая часть вашего приложения, которую надо создать или модифицировать. Такая организация сама по себе значительно упрощает процесс разработки и поддержки приложения.

Использование рабочей среды для нашего примера

Так как данный урок не имеет целью показать процесс создания приложения с помощью cakePHP, то мы покажем только код для модели, контроллера и вида с комментариями о преимуществах использования рабочей среды MVC. Код специально упрощён и непригоден для использования в реальном приложении.

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

Итак, как только пользователь нажимает кнопку, браузер запрашивает данный url:

CakePHP форматирует URL по шаблону /controller/action/param1/param2 , где action — это функция, которая вызывается контроллером. В старом классическом виде url будет выглядеть так:

Контроллер

В рабочей среде cakePHP, наш контроллер будет выглядеть так:

Просто, не так ли?. Данный контроллер будет сохранен как books_controller.php и размещён в /app/controllers. Он содержит список функций, которые выполняют действия для нашего примера, а также другие функции для выполнения связанных с книгами операций (добавить новую книгу, удалить книгу, и так далее).

Рабочая среда предоставляет нам множество готовых решений и нужно только сформировать список книг. Есть базовый класс, в котором уже определено базовое функционирование контроллера, таким образом, надо унаследовать свойства и функции этого класса (AppController является наследником Controller).

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

this->Book — это наша модель, и часть кода:


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

Метод set в строке:

Контроллер передаёт данные виду. Переменная books принимает данные, возвращённые моделью, и они становятся доступными для вида.

Теперь остаётся только вывести на экран вид, но эта функция выполняется автоматически в cakePHP, если мы используем вид по умолчанию. Если мы хотим использовать другой вид, то надо явно вызвать метод render.

Модель

Модель даже ещё проще:

Почему она пустая? Потому что она является наследником базового класса, который обеспечивает необходимую функциональность и нам нужно использовать соглашение об именах в CakePHP для того, чтобы рабочая среда выполняла все другие задачи автоматически. Например, cakePHP известно на основании имени, что данная модель используется в BooksController, и что она имеет доступ к таблице базы данных с именем books.

С таким определением у нас будет модель, которая может только читать, удалять или сохранять данные в базе данных.

Код сохраняем как book.php в папке /app/models.

Все, что нам нужно теперь сделать — это создать вид (по крайней мере, один) для списка действий. Вид будет иметь код HTML и несколько (как можно меньше) строк кода PHP для организации цикла по массиву книг, которые предоставляется моделью.

Как можно заметить, вид создаёт не полноценную страницу, а лишь фрагмент HTML (таблицу в данном случае). Потому, что CakePHP обеспечивает другой способ для определения шаблона страницы, и вид вставляется в данный шаблон. Рабочая среда также обеспечивает нас некоторыми вспомогательными объектами для выполнения общих задач во время создания частей HTML страницы (вставка форм, ссылок, Ajax или JavaScript).

Сохраняем вид как list.ctp ( list — это имя действия, а ctp означает шаблон CakePHP) в папке /app/views/books (потому, что это вид для действия контроллера).

Вот так выполняются все три компонента с помощью рабочей среды CakePHP!

Данный урок подготовлен для вас командой сайта ruseller.com
Источник урока: net.tutsplus.com/tutorials/other/mvc-for-noobs/
Перевел: Сергей Фастунов
Урок создан: 4 Августа 2010
Просмотров: 315003
Правила перепечатки

5 последних уроков рубрики «PHP»

Фильтрация данных с помощью zend-filter

Когда речь идёт о безопасности веб-сайта, то фраза «фильтруйте всё, экранируйте всё» всегда будет актуальна. Сегодня поговорим о фильтрации данных.

Контекстное экранирование с помощью zend-escaper

Обеспечение безопасности веб-сайта — это не только защита от SQL инъекций, но и протекция от межсайтового скриптинга (XSS), межсайтовой подделки запросов (CSRF) и от других видов атак. В частности, вам нужно очень осторожно подходить к формированию HTML, CSS и JavaScript кода.

Подключение Zend модулей к Expressive

Expressive 2 поддерживает возможность подключения других ZF компонент по специальной схеме. Не всем нравится данное решение. В этой статье мы расскажем как улучшили процесс подключение нескольких модулей.

Совет: отправка информации в Google Analytics через API

Предположим, что вам необходимо отправить какую-то информацию в Google Analytics из серверного скрипта. Как это сделать. Ответ в этой заметке.

Подборка PHP песочниц

Подборка из нескольких видов PHP песочниц. На некоторых вы в режиме online сможете потестить свой код, но есть так же решения, которые можно внедрить на свой сайт.

Популярные PHP MVC фреймворки

Автор статьи: Влад Кобылянский, архитектор программного обеспечения, разработчик и консультант по технологиям малого бизнеса (Майами, Флорида).

Вопрос: Что сегодня происходит с PHP фреймворками?

В феврале 2020 года я так ответил на этот вопрос:

«В основном все крутится вокруг двух PHP фреймворков — Laravel и Symfony. Особой нужны в использовании CakePHP, Zend, CodeIgniter, Yii и т. д. нет, если вы начинаете новый проект. Только если вы уже знаете эти фрэймворки или у вас в команде есть разработчики которые привыкли работать с ними, тогда причины их использования обоснованы.

Когда начинается реальная разработка, вы должны иметь возможность находить инструменты, плагины, ответы на общие проблемы. С сообществами Laravel и Symfony, с постоянным развитием новых «модулей» или функций, не будет ощущения, что вы остались «в стороне». Одни Laracast (даже если вы не работаете в Laravel) чего стоят! Они просто фантастичны.

Когда заходит речь об интеграции с iron.io или другими SaaS сервисами, поддержке широкого спектра источников данных или о среде разработки – Laravel и Symfony и их расширения намного более продвинуты.

Еще одним достоинством Lumen, является быстрая разработка и прототипирование API для Laravel. При этом это никак не ограниченно для построения больших приложений.Вообще говоря, сегодня мы определенно видим переход к контейнерной архитектуре, где MVC играет гораздо меньшую роль. Все это касается микросервисов, оркестровки и создания приложений как «функций» (AWS Lambda и подобных сервисов). Возможно, пришло время освежить наши навыки Node/JS и GoLang?»

Хотя я в целом доволен этим ответом, сейчас я думаю, что некоторые моменты пришло время пересмотреть.

Прежде чем перейти к таким странным темам, как GoLang, давайте взглянем на тенденции PHP MVC фреймворков.

Я бы сказал, что тенденции, которые мы наблюдали в прошлом, остаются. Laravel продвигается вперед, в то время как большинство остальных фреймворков отстает. В популярности Symfony наблюдается небольшой всплеск, вероятно, из-за долгожданного выпуска Symfony 3. Я попробовал более конкретные поиски для сравнения, такие как «CakePHP 3» или «ZF2», однако они не привели к статистически значимым тенденциям.

На этот раз я добавил CodeIgniter, потому что он оказалася очень популярным. Я получил ряд вопросов о CodeIgniter. Если коротко, CI сейчас не в конкуренции, потому что это не 100% фреймворк MVC. Иначе, чем организованной коллекцией POPO, я это не назову.

Для наглядности представляю вам цитату из руководства CodeIgniter:

«CodeIgniter имеет довольно свободный подход к MVC, поскольку не требуются Models. Если вам не нужно дополнительное разделение или вы обнаружите, что поддерживающие Models требуют большей сложности, чем вы хотите, вы можете их проигнорировать и создать свое приложение с помощью Controllers и Views

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

Далее, Symfony 3 привнес некоторые достойные улучшения в разработку и целый ряд новых «фич». Как и многие аналоги PHP, теперь он предлагает микро-фреймворк. ZF3, к примеру, добавил ряд улучшений, таких как поддержка PHP7 (наконец!) и даже стал микро-фреймворком. но, в их руководстве так и говорится:

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

Long Story Short

Вот как я вижу мир PHP фреймворков сегодня:

  1. Symfony или Laravel (выбор зависит от того, какую задачу вам нужно решить)
  2. Все остальное

Laravel на первом месте. Объем доступной информации, Laracasts, таланты разработчиков во всем мире, простые реализации шаблонов, интегрированные наборы инструментов тестирования, активная реализация записей в форме Eloquent, облегченная версия в Lumen, развитие Homestead (Vagrant) – все перечисленное способствует фреймворку действительно выделяться и для новых, и для опытных разработчиков.

Однако модели Eloquent могут стать непослушными и довольно большими по размеру, а сервисов Laravel (не путать с микросервисами) можно создать очень много, и вот тут люди начинают думать о реализации Repository, которому здесь не место. Так родился Monolith.

Если вам не нравится активный шаблон записи и вам нужна дополнительная гибкость в репозиториях, или, возможно, вы видите слишком много независимых анонимных функций, тогда используйте Symfony + Doctrine. Рассматриваю ли я Symfony как шлюз для монолитных приложений? В какой-то степени, да.

В целом, я бы не назвал это резким изменением с прошлого года. Тем не менее, нам нужно взглянуть на общую картину: правильно разработанное приложение выходит за рамки чистого MVC; речь идет об инфраструктуре, конвейере развертывания, разъединённой архитектуре. Все это может быть достигнуто в стеке MVC, но нужно быть внимательным, чтобы избежать Monolith.

Приход микросервисов

Раньше я упоминал о распространенности микросервисов и необходимости улучшать навыки GoLang или Node. А в статье о PHP MVC было бы глупо не упомянуть о явно растущем движении к микросервис-ориентированной архитектуре (MOA); и это движение набирает обороты, поверите вы или нет.

Хотя эти два понятия не являются взаимоисключающими, не нужно находить параллели между ними, ведь они действительно представляют собой разные философии. В качестве примера, размещение вашего приложения MVC в одном контейнере и MySQL в другом, а затем объединение их вместе, не обязательно представляет собой надлежащую MOA.

Это, безусловно, лучший подход, чем пытаться установить MAMP, XAMPP или что-либо еще, чтобы заставить ваш компьютер работать с приложением.

Кроме того, это может решить некоторые проблемы, такие как простота запуска локальной среды на разных платформах и, возможно, в некоторых случаях стратегии развертывания, но вы застрянете с монолитным MVC в вашем приложении/контейнере.

Уничтожение Monolith

Микросервисы – это как раз о «разрушении». В то время как MVC обращается к вашей структуре кода и организации, обеспечивая надежный подход к разделению проблем, эта концепция еще больше расширяется контейнерами/сервисами/MOA.

Вместо того, чтобы просто отделять виды (Views) от моделей (Models), вы теперь разделяете каждый «кусок» или логическую единицу вашего приложения на индивидуальную службу, предназначенную для правильной работы с собственными обязанностями.

Если у вашего MVC-приложения есть контроллер «Поиск», действия и соответствующие методы модели, то у нас уже есть пример монолитного приложения.

Напротив, используя подход MOA, у нас будет сервис для каждого из этих процессов. В качестве примера:

  • Router сервис
  • Request сервис
  • Query сервис
  • DataSource сервис
  • Response сервис

Но не все эти «сервисы» являются частью стека MVC? Конечно нет. Они являются строительными блоками нашего Monolith.

С MOA каждый сервис работает в рамках собственной среды, а мы, как архитекторы, можем разработать лучший подход к решению конкретного запроса.

В качестве примера, если я должен был бы написать службу обработки изображений в среде Laravel, я использовал бы что-то вроде расширения PHP-GD2, что может быть не самым эффективным способом обработки изображений. Служба C++, которая обрабатывает мои запросы в обработке изображений, может быть намного быстрее и определенно более надежной при масштабировании. И мы могли бы сделать вывод службы обработки изображений и отправить ее в службу DataStore, службу CloudStorage и службу Queue Email.

Решение этой же задачи с кучей скрытых заданий и, возможно, нескольких отдельных приложений MVC и пользовательских сценариев – это то, как разработчики делали это раньше (2 года назад). Время двигаться вперед.

Масштабируемость

Здесь возникают проблемы (или заканчиваются, в зависимости от того, куда вы держите курс). С одной стороны, очень сложно масштабировать Monolith: если вы создадите все больше и больше логики в одном и том же наборе MVC, вы застрянете с хорошо структурированным приложением ужасной сложности. С другой стороны, если вы построите тысячу микросервисов на разных языках, как вы будете управлять этим беспорядком?

Существуют различные инструменты компоновки контейнеров (например, Kubernetes, Swarm, Mesos), услуги по развертыванию контейнеров (GKE и AWS ECS), однако лишь немногие предприятия используют архитектуру Docker. Есть удачные истории в построении инфраструктуры с использованием Docker или других контейнерных технологий (т. е. GKE). Большинство из этих историй исходят от компаний, которые могут позволить себе тратить ресурсы на архитекторов, дефолтов, администраторов баз данных и инженеров. Тем не менее, сейчас идут бесчисленные дискуссии о том, как развернуть хорошо организованный и элегантный MOA.

В любом случае, вы не решите эту проблему самостоятельно, и пока вы не достигнете относительно большого масштаба, эта проблема действительно нуждается в решении. Может быть, сейчас не самое время усердствовать.

Золотая середина на сегодняшний день (даже для тех, кто занимается приложениями меньшей сложности или не такими требованиями к трафику) заключается в том, чтобы разгрузить многие типичные сервисы сторонним провайдерам. Почти все доступно сейчас как сервис. Фоновые задания, обработка изображений, аутентификация, аналитика данных, ведение журнала, отправка электронной почты, системы очереди не обязательно должны строиться в одном стеке MVC, а архитектор должен подумать о том, что может быть выгружено в систему SaaS за небольшую ежемесячную стоимость (т.е. поиск Algolia) или, возможно, специально созданную докерную службу, работающую в облачном пространстве, которая выполняет эту обработку изображений.


Я думаю, важно, чтобы вы не начали перепроектировать весь проект с начала, не сбрасывать все, что у вас уже есть, а выпускать докеры, где это можно сделать. Существуют способы постепенного развертывания вашего проекта/продукта путем разъединения, изучения узких мест в системе (и т.д.) и последующим применением разделения проблем в этих проблемных областях.

Вывод

2020 год принес нам много дискуссий и производственных развертываний, основанных на контейнерах и MOA. Мои размышления о Docker, используя GoLang или Node, не означают, что PHP «умирает» или что-то в этом роде . Я считаю, что разработчикам нужно оставаться в тренде. Если микросервисы и дальше будут развиваться в том же русле, в котором это происходит сейчас, то почему бы не изучить GoLang? Он идеально подходит (из-за низкой занимаемой площади, скорости и параллельной обработки) для разработки небольших контейнерных приложений. Node и GoLang позволяют создавать небольшие сервисы, которые являются частью более крупного проекта, связывают созданные сервисы и выпускают их как контейнеры Docker, если это необходимо в вашей работе.

Тем не менее, все эти передовые решения и языки не уменьшают значимость и востребованность языка PHP. Разработчикам еще нужны будут стеки MVC и работа с API.

MOA пока не помогает решить архитектурные проблемы на стороне frontend, UI или Views, хотя при этом контейнеры помогают нам избежать работы с Monolith на backend. Мы можем создать чрезвычайно надежное backend-приложение, но оно среагирует на JSON, который каким-то образом должен быть представлен в клиентском приложении. Имеет ли значение, если результирующий объект ответа поступает из РНР кода, URL или от модулей принятия решений и обработки, разделенных интерфейсом обмена сообщениями? Это зависит от Ваших потребностей и требований к вашему приложению.

Мастер Йода рекомендует:  Изучаем теги шаблонов

Мой совет: в этом году учите Laravel, следите за Docker, GoLang и фокусируйтесь на конвейере развертывания. Продвижение от локального небольшого проекта к продакшену должно быть достаточно плавным, особенно при создании приложений MVC.

Помощь в решении проблемы с php MVC

У меня есть группы на моем сайте, и URL-адреса имеют следующую иерархию:

Как вы можете видеть, у группы могут быть новости, галерея и т.д., и в свою очередь событие, которое находится в группе, также может иметь новости, галерею и т.д.

Как реализовать этот подход в структуре без указания какой-либо конкретной?, то есть я хотел бы получить некоторые указания о том, что будет с модулями, контроллерами и т.д.

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

Чтобы получить все это в одном простом контроллере, вы можете сделать следующее:

Группы контроллеров, действие по умолчанию

Группы контроллеров, действие новостей

Группы контроллеров, действие событий

Группы контроллеров, действие конкретного события. Здесь, в зависимости от вашей структуры, вы можете либо перенаправить ее на конкретное действие, либо вы можете протестировать действие в действии, если отправлен идентификатор и перенаправить требуемое действие конкретного события.

Edit

if events/news/whatever, у вас есть действия на них, я бы определил контроллер событий, конкретный контроллер новостей и т.д., вы можете сделать eaven дальше и разделить их все в разных модулях (например, это разрешите вам иметь adminNewsController, frontendNewsController с newsModel все в одном месте для новостного модуля).

MVC PHP: Понятие, преимущества, пример

В данной статье мы разберемся с понятием MVC, и как, на примере, можно применить это в PHP.

Понятие MVC

MVC(Model-view-controller, «Модель-представление-поведение», «Модель-представление-контроллер») — это шаблон проектирования приложений, при котором управляющая логика поделена на три отдельных компонента таким образом, что модифицирование одного из них дает минимальное влияние на остальные.

Шаблон MVC хорошо применять при создании сложных проектов, где необходимо отделить работу php программиста (или разделить группу программистов на отделы), дизайнера, верстальщика, и т.д.

Шаблон MVC разделяет представление, данные, и обработку действий пользователя на три отдельных компонента:

MVC Модель (Model). Модель предоставляет данные (обычно для View), а также реагирует на запросы (обычно от контроллера), изменяя своё состояние.

MVC Представление (View). Отвечает за отображение информации (пользовательский интерфейс).

MVC Поведение (Controller). Интерпретирует данные, введённые пользователем, и информирует модель и представление о необходимости соответствующей реакции.

Для наглядности схемы действия шаблона MVC, ниже предоставлена иллюстрация.

Такие компоненты как представление и поведение зависят от модели, но никак не влияют на нее. Модель может иметь несколько представлений. Может быть, концепция MVCсложная для понимания, но если ее осмыслить, она становиться незаменимой при разработке приложений на PHP.

MVC в PHP

Особенностью при использовании MVC в PHP, является то, что существует одна точка входа в php приложение, которая, например, достигается следующим образом. Создается index.php через который будут обрабатываться все запросы, для этого создаем в папке с индексом файл .htaccess и помещаем в него такой код:

В предоставленном коде, первой строкой, проверяется существование запрашиваемого файла, и если его нет, то идет перенаправление на index.php, иначе даже запросы картинок сайта будут перенаправляться на индекс. Последняя строка кода преобразовывает запросы вида index.php?route=chat/index у вид index.php/chat/index. Если у вас нет возможности использовать ModRewrite в своем приложении, то вам придется делать переадресацию вручную.

PHP Модель

Данные о PHP модели содержаться в ее атрибутах и могут быть изменены только через специальные функции. Модель может содержать в себе несколько представлений. Как правило, phpмодель это класс работающий с БД, конкретнее: запись, чтение, удаление. Естественно чтение информации с БД может быть реализовано несколькими представлениями (функциями). Как пример модель статей на сайте: можно получить конкретную статью из БД, список последних, популярных, какой-то категории… это все представления модели. Для наглядности ниже предоставлен пример php модели.

PHP контролер (Поведение)

PHP контролеры получают запросы пользователей, которые мы направляли через index.php, и в соответствии с ними, корректируют работу модели. Правильнее сказать контролируют работу php приложения.

PHP Представление

Представление отслеживает изменение в модели и создает или меняет интерфейс php приложения.

Как работает данный PHP MVC шаблон?

При обращении пользователем по нужному url выбирается соответственный контролер, который обращается к представлению и модели, и выводится информация. Другими словами контролер в mvc есть связующим звеном модели и представления.

Преимущества MVC шаблона при создании PHP приложения

Как упоминалось выше это, прежде всего дифференциация разработчиков php сайта на отделы. Также увеличивается скорость работы php приложения, если создается крупный проект. Ну и то, что касается непосредственно самого php разработчика, это правильная структуризация php кода (все на своих местах, так легче для понимания).

MVC пример

Особо не будем зацикливаться на примере работы MVC, так как уже имеется пример mvc на php. Добавлю лишь еще пару схем для более глубокого понимания.

Еще одна схема работы MVC шаблона на PHP, она более чем доступна для понимания.

Теперь можно сказать, что понятие mvc раскрыто. Если вы впредь не использовали MVC шаблон при организации создания вашего проекта, то советую вам не медлить с применением полученных знаний. Если еще сомневаетесь – читайте пункт преимущества mvc шаблона. Если же имеете практические предложения по поводу использования mvc в php, просьба высказаться в комментариях.

MVC (Model-View-Controller) в PHP

Пока я не стал баловаться программированием на Javа, особо не задумывался над использованием MVC в PHP. Обычно действуешь по своему опыту или как это принято в php-фреймворке (или CMS, не важно). Тем более почти все фреймворки декларируют свою преданность концепции MVC: дескать вот у нас всё сделано правильно, по теории.

После Java, где объектное программирование возведено почти в абсолют, MVC в PHP выглядит уже достаточно «бледно», пытаясь хоть как-то соответствовать этой концепции. Интересно ещё и то, что php-разработчики Model-View-Controller видят по разному и не всегда верно.

Базовая концепция Model-View-Controller

Основа MVC была заложена аж в 1978 году для Smalltalk. Она безумно простая и учитывала реалии того времени. Если чуть утрировать, то Контролёр — это устройство ввода — клавиатура и её обработчики (например драйвера). Как только в Контролёре что-то произошло, например пользователь нажал клавишу, это событие/данные передаются в Модель. Именно в Модели решается что именно нужно сделать с введенной информацией. Например, если нажата Enter, то происходит запуск введенной команды.

После того, как действие выполнено, необходимо как-то его отобразить. За это уже отвечает Вид (Представление) и в простом варианте это обычный монитор, принтер или файл.

Смысл был в том, чтобы выделить из общей кучи кода модули ввода/вывода, оставив основную функциональность программы в виде Модели.

Со временем MVC приняла более абстрактный вид, но общая концепция не изменилась.

  • Контролёр указывает модели что нужно сделать.
  • Модель выполняет работу.
  • Вид отображает/отдаёт результат.

В классических приложениях Model-View-Controller реализуется довольно просто, поскольку состоят из статичного интерфейса. На этапе разработки программы, заранее создается форма, где располагаются кнопки, метки, меню и прочие элементы, которые не будут менять своего расположения, форму или дизайн во время выполнения программы.

Поэтому взаимодействие с пользователем здесь довольно просто реализуется через Контролёр, который понимает, что нажата какая-то кнопка и нужно выполнить определенное действие. Но с PHP всё сложней.

Работа web-приложения

Сайт может взаимодействовать с пользователем разными способами. Например нажатие кнопки, по которому появится всплывающий popup. То есть onClick кнопки должен отслеживаться Контролёром, хотя программно это HTML-код, который вроде как уже Представление.

Однако во всех сайтах есть одна общая черта — все они взаимодействуют через URL-адреса. Любая ссылка — это указание на действие. Например вывести главную страницу, или записи рубрики, или отправить форму по ajax-запросу (там тоже URL). То есть во всех случаях пользователь передаёт своё действие в виде ссылки (http-запроса).

Другой вариант — это действия, где происходит скрытая передача данных через POST (Ajax). Адрес страницы при этом не меняется, хотя обработчик уже должен как-то понимать, что если это post-запрос, то нужно сделать одно, а если get, то просто вывести типовую страницу.

Таким образом, в web-приложении Контролёр должен иметь функции роутинга. Реализация роутинга разнится, но во всех случаях представляет собой в первую очередь разбор URL на части, например с помощью parse_url() и определения метода передачи данных ($_POST и т.п.).

Роутинг в Контролёре определяет дальнейшее действие, которое сильно завязано на структуру приложения. Например можно вызвать функцию, подключить файл или выполнить метод php-класса. См. для примера PHP-роутинг (Routing) для новичков.

В любом случае Конролёру нужно точно знать что дальше делать и какой функциональный модуль будет выполнять эту работу. Также возможен вариант, что Контролёр только передает входящие данные в Модель, которая уже сама принимает решение какой модуль будет выполнять задачу. По сути это одно и тоже, разница лишь в том, где именно будет размещён это «action list».

После того, как управление переходит к Модели, происходит основная работа, то есть то, ради чего посетитель вообще зашёл на сайт. Предположим, что это примитивный вывод даты и времени. В Модели можно сразу же сформировать необходимый html-код для вывода, но это уже будет нарушать концепцию MVC, поскольку Модель должна отдавать только данные, а сама визуализация должна выполняться в Виде.

Вид/Представление по своей сути — это результирующий html-код, который помимо всего прочего, верстается под необходимый дизайн. Скажем, если нужно вывести дату другим цветом, всё что потребуется сделать, так это поменять css-стили в шаблоне. При этом ни Контролёр, ни Модель не меняются.

Проблемы View

Здесь мы сталкиваемся с проблемой: как именно можно передать данные в html-код? Ведь HTML статичен — это не язык программирования, а всего лишь вид разметки документа.

Даже в самой простой реализации, html-шаблон нужно будет сделать в виде php-файла, где придётся смешивать html и php-код между собой. В простых случаях это не проблема, но когда данных для вывода много, то такая смесь уже представляется серьёзной проблемой (низкая читабельность и сложная поддержка).

К сожалению решения этой проблемы не существует, хотя есть методы, которые позволяют упростить написание такого кода (об этом ниже).

Неверное понимание MVC


Очень часто встречаются искаженные толкования Model-View-Controller. Вопрос здесь скорее в практической реализации: PHP очень гибкий язык и позволяет использовать любой подход. Не думаю, что кто-то бросится переписывать свой проект под строгий MVC, но понимание этой концепции может пригодится при создании нового.

Часто под Моделью понимают только работу с базой данных. То есть контролёр вызывает некую функцию/метод Модели, которая возвращает сырые данные. Здесь проблема в том, что кто-то должен эти данные обработать. То есть Модель в этом случае не выполнила всю работу и данные должны быть обработаны либо уже в Представлении, либо в том же Контролёре. В обоих случаях это уже проблема.

Работа с БД — только часть работы Модели. Ни Контролёр, ни Вид не должны ничего знать ни про базу, ни про то, как получаются данные. Для них Модель — это черный ящик, куда можно передать входящие данные и получить готовые.

Другим искажением MVC будет считать Контролёр ответственным за всю логику и работу приложения. С одной стороны, он действительно отвечает за маршрутизацию, но в нём не должно быть логики выполнения. По хорошему, Контролёр даже не должен ничего знать и о Представлении. Когда Контролёру отводится другая роль, то это уже другая концепция: Model-View-ViewModel, Model-View-Presenter и т.п.

Модульность PHP

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

Если проект основан на ООП, то обычно стоит задача организации многочисленных классов. Например в CodeIgniter 2/3 версий каждый класс представлял собой отдельный файл, но все файлы всех классов находятся в одном общем каталоге. Это накладывает некоторые ограничения, поскольку требует размещения всего кода относящегося к классу в один файл.

В CodeIgniter 4 уже используется модульный подход, где классы размещаются в отдельных каталогах и могут состоять из нескольких файлов.

MVC — лишь концепция, поэтому практическая реализация может быть разной. Обычно используют ООП, поскольку это решает проблему пространства имён в PHP, а модульность упрощает поддержку классов. Хотя использование классов и ООП не означает следованию MVC.

View не так прост

Ошибочно принято считать, что html-шаблон — это единственное, что отводится Виду. На самом деле это порождает проблему смешивания html и php-кода, о которой я написал выше.

В простом варианте это может выглядеть так:

На помощь может прийти php-шаблонизатор, который позволит использовать более простой синтаксис, что улучшает читабельность:

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

Другой вариант решения — это переместить html-код в сам php-шаблон. То есть это уже будет php-код, который выводит html. Понятно, что здесь уже можно произвольно усложнять логику вывода данных.

Такой подход наиболее часто встречается в CMS-шаблонах. Проблема здесь в том, что вместо html-верстки мы вынуждены заниматься php-программированием.

Также View обычно разбивается на несколько частей/файлов. Например секция HEAD, после компоненты шапки, вывод основного контента, сайдбар и подвал. Здесь главное разделить блоки по функциональному признаку и так, чтобы между ними по возможности не было зависимостей.

Расскажу про ещё один вариант, который я придумал для своей MaxSite CMS. Используется специальный php-класс для форматированного вывода. Вначале в него загружаются данные записи, после этого задается формат вывода, где можно указать дополнительные параметры, а сам вывод осуществляется в виде метода, который делает замены «псевдокода» на основе реальных данных и заданного формата.

Таким образом, View не просто вывод шаблона — это обработчик шаблона, который подключает разные модули/блоки/файлы, использует шаблонизатор, а также может содержать сложную логику вывода данных.

Архитектура приложения

Можно ли реализовать строгую MVC в PHP? Если вопрос стоит принципиально, то PHP без проблем реализуется какой-то один из шаблонов проектирования, реализующий MVC: Наблюдатель, Стратегия и Компоновщик и т.д. Всё это взаимодействие между классами в рамках ООП, с которым у PHP нет проблем.

Но с моей точки зрения, более важным будет общая архитектура приложения и практическая реализация отдельных модулей. Например в том же CodeIgniter 2/3 конфигурация представляет собой обычный массив, а в 4-й версии — это уже PHP-класс, который работает с таким же массивом, но уже внутри себя. То есть это более строгое следование теории, но с практической точки зрения — бессмысленное раздувание кода. Или, скажем, во многих случаях удобней и проще воспользоваться обычной require_once() вместо создания сложного загрузчика php-классов.

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

Создание движка на MVC. Пишем роутер.

Привет всем! Вот и наступила вторая статья из серии, посвященной созданию движка на MVC. Сегодня мы создадим роутинг. Поехали!

Для начала разберемся, как будет работать наш роутинг. У нас будет единая точка входа — index.php. Туда будут отправляться все запросы. URL будет такого вида:

Т.е. сначала будет идти контроллер, потом метод, а потом параметры. Этот URL будет разбираться нашим роутером и будет вызываться переданный метод у переданного контроллера с параметрами(если есть).

Думаю, как это будет работать, вы поняли. Теперь откроем файл .htaccess и пропишем следующее:

RewriteEngine On
RewriteCond % !-d
RewriteCond % !-f
RewriteCond % !-l
RewriteRule ^(.+)$ index.php?url=$1 [QSA,L]

Разберемся, что мы здесь написали. Сначала включаем движок перезаписи, потом задаем 3 условия: если это не физическая директория, файл или ссылка, то берем весь URL и отправляем на файл index.php(нашу единую точку входа), передав GET параметр url со значением нашего URL.

Теперь что бы вы не ввели в адресную строку, вы всегда будете попадать в файл index.php. Давайте перейдем в этот файл и пропишем следующее:

Теперь вы увидите ваш url. Давайте создадим контроллер index.php в папке controllers.

Теперь в нашем главном файле index.php подключим его

Теперь мы увидим надпись, которую выводит конструктор нашего класса. Создадим еще один контроллер help.php в папке controllers.

Теперь если в адресной строке после названия сайта(домена) ввести ‘/help‘, вы увидите, что сработал контроллер Help.

Итак, думаю, вы поняли, как это работает. Теперь, чтобы не затягивать, я приведу сразу готовый код главного файла index.php, а потом поясню его.

Вот такой вот получился файл index.php. Сначала мы получаем наш url адрес и записываем его в переменную $url. Дальше наш нужно удалить последний слэш, иначе у нас будет ошибка. Для этого мы воспользовались функцией rtrim, куда первым параметром передаем, что мы хотим удалить, а вторым — где. После, используя функцию explode мы разбиваем нашу строку на массив по слэшу. Теперь первым параметром у нас будет название контроллера, который мы и подключаем строчкой ниже и создаем его объект. Теперь проверяем, есть ли параметры. Если да, то вызываем переданный метод и передаем параметр, а если нет, то просто вызываем наш метод.

Давайте теперь в нашем контроллере help.php создадим метод other.

Теперь напишем в адресной строке следующее: ваш_домен.ru/help/other

И у нас вызовится метод other контроллера help.

Теперь изменим наш метод other

Теперь в адресной строке браузера напишем так: ваш_домен.ru/help/other/10 В метод передастся 10, и он это выведит.

Итак, вот мы уже и сделали наш роутер рабочим. Конечно, это только начало, но оно уже положено. Дальше будет только интересней. Спасибо за внимание!

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

Она выглядит вот так:

  • BB-код ссылки для форумов (например, можете поставить её в подписи):
  • Комментарии ( 15 ):

    Ссылку на наработанный материал прилепляй. Люди спасибо скажут.

    Лучше сами все делайте и копируйте код, а вообще хорошо будет, если вы будете его переписывать. Для закрепления самое то! А готовый движок будет в последней статье.

    Краще використовуйте nginx. Там і синтаксис реврайтів простіший і швидше працює. Для тестування на віндовс є — winginx.

    Михаил а возможно ли создать видео урок по теме MVC на основе этой серии статей мне механизм MVC мало понятен ,то есть теоретически да но как практически это действует не очень, а на основе практического маленького движка в видео формате ,в видео мне понятней, может и пойму. ПЛИЗ ПЛИЗ ПЛИЗ.

    Михаил, у вас на — этой странице опечатка. У вас так: вы увидите, что сработвал контроллер Help. А надо так: вы увидите, что сработал контроллер Help. Кстати, Михаил, а почему бы не соединять файлы таким образом: $this->load->view(‘header_view’); тогда и require не понадобится. И ещё. Почему не отображается моё имя, а в место него выводиться логин?

    $url = $_GET[‘url’]; не ноходить url

    Здравствуйте, а как сделать чпу как в joomla? Роутинг не совсем подходит так как нужна динамика ссылок 2-го уровня.

    Добрый день, Михаил. Подскажите пожалуйста, скопипастил код, но url в _GET массив не попадает — это не отрабатывает htaccess? Как его нужно поправить? Спасибо

    Здравствуйте. Очень классный сайт и очень мне помог. Но в вашем примере главного файла index.php есть такая проблема: если мы переходим по ссылке site.com/index то открывает файл который находится в controllers/index.php. Но а что если файл в controllers/index.php главная страница и нужно чтобы по адресу site.com/ открывался файл controllers/index.php? В данном примере автора если перейти на site.com то отображает ошибку «Warning: require(controllers/.php): failed to open stream: No such file or directory» Вот решение. В моем случае главный файл index.php: $url[1]($url[2]); > else < if(isset($url[1])) < $controller->$url[1](); > > ?>

    Тут в коде главного файла ошибка, после: Ответить

    Да, после добавления вашей подсказки ( if (!$url) $url = ‘index’; ) сработало. До ннеё выводилась ошибка: Warning: require(controllers/.php): failed to open stream: No such file or directory in E:\OpenServer\domains\my-mvc\index.php on line 6 Fatal error: require(): Failed opening required ‘controllers/.php’ (include_path=’.;e:/openserver/modules/php/PHP-5.5;e:/openserver/modules/php/PHP-5.5/PEAR/pear’) in E:\OpenServer\domains\my-mvc\index.php on line 6. Теперь выводится такая строчка: Мы в контроллере INDEX

    тогда зачем городить. проще сразу написать $url = ‘index’; ))) вопрос почему php $url = $_GET[‘url’]; это не работает?

    прям со старта не заводятся) в $url не передается гет

    Присоединюсь к выше сказанному, тогда уже вот так: [code] $url = $_GET[‘url’]; define(‘DS’, ‘/’); define(‘ROOT’, $_SERVER[‘DOCUMENT_ROOT’]); define(‘CTRL’, ROOT . DS . ‘controllers’); $url = isset($url) ? strtolower($url) : ‘index’; require_once(CTRL.DS.$url.’.php’); $controller = new $url; [/code]

    Если вместо Apache используется NGINX, то .htaccess не вариант. Для NGINX надо добавить в конфиг: location / < try_files $uri $uri/ /index.php?url=$request_uri; >

    Для добавления комментариев надо войти в систему.
    Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.

    Copyright © 2010-2020 Русаков Михаил Юрьевич. Все права защищены.

    Добавить комментарий