Model в MVC на PHP


OpenSource в заметках

Паттерн Model-View-Controller (MVC), открытый в в конце 1970-х, представляет собой шаблон проектирования архитектуры программного обеспечения, основной задачей которого является отделение функций работы с данными от их представления. Теоретически, грамотно спроектированное MVC-приложение позволит фронтенд и бэкенд разработчикам в ходе работы не вмешиваться в зоны ответственности друг друга, то есть фронтенд-разработчику не понадобиться что-либо знать о «кухне» своего бэкенд-коллеги и наоборот.

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

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

Понимание MVC

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

Эта схема наглядно показывает однонаправленность потока информации в паттерне, а также описывает роли каждого компонента.

Модель

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

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

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

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

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

Существуют некоторые заблуждения относительно предназначения представления, особенно в среде веб-разработчиков, которые только начинают строить свои приложения с использованием MVC. Одним из наиболее часто нарушаемых правил является то, что представление никоим образом не должно общаться с моделью, а все данные, получаемые представлением должны поступать только от контроллера. На практике же разработчики часто игнорируют эту концепцию, стоящую в основах MVC-паттерна. В статье Fabio Cevasco The CakePHP Framework: Your First Bite наглядно показан этот сбивающий с толку подход к MVC на примере фреймворка CakePHP, одним из многих нестандартных MVC-фреймворков:

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

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

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

Контроллер

Контроллер — это последняя часть связки MVC. Задачей контроллера является получение данных от пользователя и манипуляция моделью. Именно контроллер, и только он, является той частью системы, которая взаимодействует с пользователем.

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

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

MVC в PHP

Предлагаю попробовать реализовать описанное выше в небольшом приложении. Начнём с того, что создадим классы модели, представления и контроллера:

Основные классы готовы. Теперь давайте свяжем их вместе и запустим наше приложение:

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

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

И в завершение немного модернизируем связующий код:

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

Итоги

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

MVC в PHP

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


Теория MVC

MVC — это сокращение названия шаблона программирования Model-View-Controller . Этот шаблон используется для отделения данных от логики и представления. Допустим, есть у нас пользователь, он будет моделью , так как содержит данные. Чтобы показать данные, мы создаём форму, в которую передаём этого пользователя. Это будет вид . Форма может содержать разные кнопки для изменения данных, то есть модели. Чтобы управлять кнопками, к форме привязывают контроллер , который ждёт нажатия кнопок и меняет модель. Таким образом достигается чёткое разделение обязанностей: модель хранит данные, вид показывает, а контроллер изменяет. При таком подходе одна модель может иметь много разных видов, а они, в свою очередь, контроллеров.

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

MVC и PHP-фреймворки

Не могу точно сказать, кому пришла “гениальная” идея взять шаблон для десктопа и перенести его в веб, но, начиная с первого Zend Framework, MVC стало уже чем-то вроде стандарта. Все современные фреймворки так или иначе используют этот шаблон. Правда, как это часто бывает, при переносе перевернули всё с ног на голову. Теперь контроллер принимает запросы, инициализирует модель, выполняет какую-то логику и передаёт данные виду. В общем-то и шаблон надо было бы переименовать в CMV, но этого не произошло, все фреймворки гордо именуются MVC.

По факту MVC в современном PHP означает, что HTTP-запрос всегда обрабатывается объектом контроллера, а наличие модели и вида вовсе не обязательно. На мой взгляд, от изначальной идеи MVC остался “огрызок”. Если изобразить на схеме, то выглядит это примерно так:

Именно такую схему реализуют фреймворки, гордо именуя её MVC. Где тут модель и вид? А их тут просто нет, кому они вообще нужны…

Проблемы MVC в PHP

Из-за подмены понятий изначального шаблона и “того, что имеем” возникает масса путаниц. Например, где хранить бизнес-логику? Вики говорит, что в модели, а здравый смысл шепчет: “в контроллере”. Потому что контроллер есть всегда, а вот модель и вид… как карта ляжет. А вот ещё вопрос, почему на второй схеме есть роутер и действие , а в аббревиатуре никаких букв по этому поводу нет? Наверное, можно придумать массу теорий на этот счёт, но ответ очевиден, это другой шаблон.

Но даже, если отбросить роутеры, действия и прочие нестыковки, то всё равно остаётся один серьёзный вопрос — что является моделью в MVC для веба? Может быть, таблица базы данных, массив, композитный объект? А что делать, если на странице ДВА объекта-модели? На эти вопросы современные фрейворки не любят давать ответы, мол, не нравиться, не ешь. Но при этом активно гнобят тех, кто пытается засунуть логику (например отправку письма или запрос к базе) в контроллер, называя это “плохой практикой”.

Хорошая практика MVC по версии фреймворков

Руководство Yii 2 гласит: “Yii приложения организованы согласно шаблону проектирования модель-представление-контроллер (MVC)”. На практике там действительно есть папки, которые называются “модели”, “виды”, “контроллеры”. Но, если копнуть глубже, то, вида может и не быть, модель тоже опциональна. Зато всегда есть контроллер, действие и много чего ещё.

Остальные фреймворки, плюс-минус, организованны по тому же принципу: на основании URL определяется контроллер ( controller ) и функция ( action или действие ), которая затем вызывается. В качестве аргументов в функцию может передаваться объект запроса или какие-то части URL. В теле функции можно обработать входные данные (через модели или абы как) и подключить вид. Некоторые фреймворки подключают вид сами, более порядочные ждут, когда вид вызовут.

Рассмотрим примеры контроллеров популярных фреймворков:

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

Проклятье MVC

Когда мне предлагают использовать тот или иной “суперклёвый” фреймворк (в основном это MVC-фреймворки), я сразу уточняю, а куда там можно запихать две тонны и маленькую тележку говнокода. Я пока не видел крупных проектов, в которых был бы только чистый код.

Если контроллер сделан в виде класса, то он должен подчиняться правилам написания классов ( принципы SOLID ). Это значит, что туда нельзя запихать даже маленькую тележку, не говоря уже о двух тоннах.

На практике люди пихают в свои контроллеры даже не тонны, а мегатонны всего, что только можно и нельзя. По какому-то неведомому принципу контроллер = справочник. Назвался AlbumController , будь добр уметь создавать, обновлять и удалять альбомы. Это хорошо, когда справочник простой и понятный, а что делать, когда нужен справочник-матрёшка? Например, справочник исполнителей в альбоме. А у исполнителей есть свои альбомы, да ещё и с обложками и историей покупок.

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

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

Есть ли жизнь без MVC?

Есть. Не используйте MVC-шаблон для веба в реализации от популярных фреймворков. Изобретайте своё, фантазируйте. Помните, что “своё” не “пахнет”.

Мастер Йода рекомендует:  Как создать сайт Советы для новичков

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

Вот так может выглядеть action без MVC :

А вот пример разработки кабинета без MVC:

Your browser does not support HTML5 video.

Сделать подобный интерфейсе на “обычном” фреймворке, на мой взгляд, очень проблематично. Это хорошо, когда у вас много программистов, включая фронтэндеров, но этот проект я делал один при сильно ограниченном лимите часов разработки. Если бы я попытался идти по пути, например, Yii 2, то только представьте сколько форм, моделей, контроллеров пришлось бы создавать и как-то связывать вместе.

© 2020 Антон Прибора. При копировании материалов с сайта, пожалуйста, указывайте ссылку на источник.

MVC- грамотная реализация модели

Здравствуйте!
Осваиваю ООП+MVC, брал пример из http://habrahabr.ru/post/150267/
Хочу научиться вести порядок у себя в классах, по всем стандартам, чтобы и другие могли разбираться в моём коде
Вот такая структура каталогов (4 папки):
core:


в core/model.php такой код:

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

мои варианты:
1) все универсальные классы, положить в каталог core и:
а)вызывать из model_portfolio.php посредством

2) сделать тоже самое, но положить все вспомогательные классы в папку Models

Или надо как-то сортировывать? Часто используемые классы, которые потребуется в Любом проекте, положить в core, а классы, которые также часто используются, но для одного отдельного проэкта — положит в папку Models?

Например класс по работе БД, я сделал статическим, и положил в core, может и тут ошибся?

02.09.2014, 08:27

Грамотная реализация MVC ООП
Доброе утро всем, уже вторые сутки лазию в просторах интернета и не могу найти нормальную.

Модели MVC и связанные таблицы
Всем привет! Прошу помочь знающих с выбором паттернов/структуры моделей для решения следующей.

Куда деть написанные функции в MVC-модели?
Я нашёл похожую тему в поиске(http://www.cyberforum.ru/php-oop/thread1250032.html), но я пока.

Реализация autoload на mvc
Подскажите как мне избавится от include в моем маршрутизаторе, и реализовать функцию autoload для.

Реализация CRUD MVC
Здравствуйте. Извиняюсь за глупый вопрос, может не правильно формулирую и вообще не о том думаю.

02.09.2014, 13:11 2 02.09.2014, 18:13 [ТС] 3

положить в папку model/extensions или отдельно extensions?

Значит основные классы, всюду используемые, держать в core.
В папке model хранить только то, что относится к контроллеру(controller) и виду(view) (model_portfolio.php и ничего лишнего)
В extensions, всё вспомогательное для проекта
Я правильно понял?

02.09.2014, 18:31 4 02.09.2014, 19:57 [ТС] 5

Ок, хорошо.
Получается, классы в папках models,extensions,core — это всё и есть Модель (из MVC)
С core всё ясно, теперь мне бы чётко понять, как различать extensions и models.
В models складывать те классы, которые используются единожды, для определенного запроса?

И как вызывать классы из extensions — в моделях, или в контроллерах?

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

Model в MVC на PHP

И так начнем. Паттерн MVC подразумевает одну точку входа – index.php, через это скрипт будут проходить все запросы, через него будет работать вся логика проекта. Для того чтобы реализовать такой подход необходимо настроить сервер, подразумевается, что сайт работает на сервере apache, поэтому нам достаточно создать файл .htaccess, в котором мы укажем правила маршрутизации URL. Помимо определения точки входа, маршрутизация позволяет создавать ЧПУ(человеко-понятные урлы). То есть после правильной настройки, адреса страниц буду выглядеть вот так site.ru/article/new.
Для начала, давайте составим .htaccess, который перенаправит обработку всех страниц на скрипт index.php. Код выглядит вот так:

Файл .htaccess должен лежать в корневой папке сайта, тут же необходимо создать скрипт index.php, который является точкой входа. Давайте запишем в index.php одну строку, для проверки работы перенаправления:

Теперь можно проверять работу перенаправления, введите любой адрес и посмотрите, что получиться: test-mvc.web/sdf/sdf/ или test-mvc.web/sdf/sdf/2342/не важно, на экране в любом случае, должно появиться «Test». Если Вы увидели эту надпись, значит, у нас все получилось.
Продолжим, давайте для удобства создадим в корне сайта файл config.php, в котором будем задавать различные константы, облегчающие своим существование настройку сайта. Это могут быть различные пути к скриптам, подступы к базе данных и так далее. Сейчас в конфиге давайте зададим следующее:

Для того, чтобы константы и другие данные конфига мы могли использовать во всем проекте, в файле index.php необходимо подключить скрипт config.php.
Помимо подключения файла с настройками, в index.php нужно создать подключение к базе данных, подключить скрипт с ядром сайта и запустить роутер, в котором будет происходить маршрутизация.
Теперь по порядку, создание соединения с базой данных будет находиться в index.php для того, чтобы соединение открывалось только один раз. Единожды открыв соединение, мы сможем использовать его во всех контроллерах и моделях, но об этом чуть позже. Сейчас просто создадим соединение с базой. Для работы с бд я решил использовать PDO. Подробнее почитать про PDO можно тут.
Ядро сайта расположим в папке core и назовем скрипт core.php, тут мы напишем функцию, которая будет сама подключать, необходимы для работы классы. Такая функция очень облегчит и упростит нам работу с контролерами, моделями и тд. Поскольку, забегая вперед скажу, что каждый контролер и каждая модель будут представлять собой отдельный класс.
Помимо авто подключения классов, добавим в ядро создания хранилища (реестра), в котором будем хранить все необходимые объекты и переменные, которые могут пригодиться в любом месте проекта.
Роутер тоже подключим в индексном файле, он будет анализировать URL и подключать необходимый контроллер и экшен. Что такое контролер я писал в предыдущей статье, а информацию про экшен я пропустил умышленно, не став нагружать лишней информацией. Так что же такое экшен?
Контролер это класс, в котором заключены различные методы, при MVC подходе каждый метод будет являться экшеном. То есть экшен(action) – это метод класса, который будет обрабатывать данные и передавать их в представление (в шаблон). Может быть, пока не совсем понятно, но после примера все станет на свои места.
На данном этапе теории достаточно, давайте перейдем к практике. Приведу код файлов, работу которых, я описывал выше.
Код скрипта index.php:

Класс хранилища Registry.php, будет находиться в папке /classes/

Код файла router.php, который находиться в папке /classes/

Теперь необходимо создать папки для хранения контроллеров, шаблонов и моделей – в корне создадим три папки controllers, views и models. И создадим несколько тестовых файлов /controllers/index.php, /views/index/index.php и /models/model_users.php, а теперь заполним файлы:
Для контроллера:

Как вы могли заметить, класс контролера наследуется от родительского класса Controller_Base. Это сделано, для того, чтобы упростить класс контролера. Поскольку нам еще необходимо подключать класс для работы с шаблонами, его подключение вынесено в Controller_Base.
Приведу его код, он расположен в папке /classes/ и называется controller_base.php :

Теперь осталось только разобраться с шаблонами. В абстрактном классе Controller_Base мы вызываем класс Template и передаем ему имя шаблона и имя контроллера.
Код класса Template, который лежит тут /classes/ и называется template.php


Если вы внимательно прочитали код, то наверняка поняли, что для отображения на страницах у нас используется шаблон first_layouts и вьюха(отображение) index.php – ее код я приводил чуть выше. Все что нам осталось, это создать файл шаблона first_layouts. Расположим его в папке /views/layouts/first_layouts.php
Шаблон будет содержать вот такой код:

Вот и все, на этом создание «каркаса» закончено. Сейчас у нас получилась самая простая структура, использующая в своей основе паттерн MVC.

Создание движка на MVC. Выводим страницы. Часть 1.

Всем привет! Продолжаем строить собственное MVC приложение, и сегодня мы начнем заниматься выводом страниц.

Создадим файл View.php в папке libs.

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

Открыв страницу, мы должны увидеть надпись «Это вид».

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

Теперь создадим папки index и error в папке views. Они будут отвечать за представление index страницы и страницы ошибок. В папке error создадим новый index.php файл и пропишем следующее

Это страница ошибки!

Теперь создадим файл header.php в самой папке views с таким содержанием

Перейдем в файл error.php, который находится в папке error и добавим в конструктор вызов метода render.

Теперь на странице мы увидим «Header Это страница ошибки!»

Давайте немного улучшим наш контроллер, добавив к нему перед вызовом метода render следующее:

view->msg = ‘Страницы не существует!’;
$this->view->render(‘error/index’);
>
?>

А теперь в файле index.php, который отвечает за вид ошибки, вместо нашей надписи «Это страница ошибки!» выведим то, что хранится в свойстве msg.

Теперь нам вывелась наша надпись.

Давайте теперь создадим модель help_model.php в папке models.

Теперь откроем контроллер help.php из папки controllers и добавим вызов нашей модели

Дальше нужно создать базовую модель. Для этого создайте файл model.php в папке libs.

Наша модель будет работать с базой данных, но пока что закомментируем это, т.к. у нас еще нет базы данных.

Подключим нашу базовую модель в нашем главном файле index.php.

require ‘libs/Bootstrap.php’; require ‘libs/Controller.php’; require ‘libs/model.php’; require ‘libs/View.php’;

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

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

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

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

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

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

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

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


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

    надпись «это вид» должна появится на главной странице? (site.ru) У меня выводится надпись «Контроллер обработки ошибок» что не так? еще заметил «Перейдем в файл error.php, , который находится в папке error» вроде этот файл еще не создавали?

    «Для этого создайте файл model.php в папке libs.» замените на «Для этого создайте файл Model.php в папке libs.». соответственно в «index.php» нужно написать вместо «require ‘libs/model.php’;» с большой буквы Model.

    Все равно не понятно. «Перейдем в файл error.php, , который находится в папке error» на каком этапе этот файл появился?

    Да, описание действий несколько не точное. 🙂

    Народ, кто в тупике. Читайте строчку — «Перейдем в файл error.php, который находится в папке error. » как — «Перейдем в файл error.php, который находится в папке controller. «

    Во! Спасибо! А то тоже не понял куда впихнуть.

    Дойдя до конца этого урока у меня появилась 500 ошибка. Что-то сбилось с .htaccess. Работают только страницы с указанием роута. Например site.loc/index/ или site.loc/help/

    Я думаю нельзя использовать много одинаковых файлов типа index.php error.php

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

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

    Model в MVC на PHP

    Архитектура веб-приложений в первую очередь определяется самой природой веба, тем, как работает HTTP. Последовательность запрос-обработка-ответ — базис, на который нанизывается все остальное. Фреймворки идут дальше и разделяют приложение на дополнительные слои уже внутри самого процесса обработки запроса. Такое разделение напрашивается само собой, без него код быстро превращается в мешанину из запросов к базе данных, формирований html и логики обработки данных.

    Мастер Йода рекомендует:  Исправление дефектов с помощью инструментов ретуши

    Из обработки запроса естественным образом выделяется слой шаблонов, на основе которых генерируется HTML. Этот слой принято называть View (представление). Кроме него, как минимум, выделяют ещё два слоя: Model (модель) и Controller (контроллер). Остальное добавляется по мере роста сложности приложения. Аббревиатура MVC (Model-View-Controller) — тема нашего урока.

    Существует две разных версии MVC. Та, которая была придумана изначально (в сообществе программистов на SmallTalk), создавалась под толстые клиенты, а они представляют собой событийные системы, как современные фронтенд-приложения. На сервере используется другая вариация MVC, которая называется MVC v2. Буквы в ней те же, но означают местами другое, и самое главное, что совсем по-другому строится взаимодействие.

    Пример шаблона проектирования MVC в PHP

    Шаблон проектирования MVC представляет собой шаблон программной архитектуры «Модель-Представление-Контроллер». MVC — это один из способов организации кода и набор рекомендаций, описывающих ряд правил. Задача MVC заключается в том, чтобы наш код проще воспринимался и читался, а также быстрее обрабатывался компьютером.

    Главная идея MVC — отделить внешний вид приложения от его логики. Здесь мы говорим о веб-приложениях, поэтому внешний вид в данном случае — это HTML-разметка и CSS-оформление. А вот под логикой понимаются разнообразные скрипты, классы, функции и пр.

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

    Основные составляющие MVC

    Как уже было сказано выше, главными составляющими шаблона проектирования MVC являются 3 части: Контроллер, Представление и Модель. Визуально это выглядит следующим образом:

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

    Модель

    «Модель» — это постоянное хранилище данных, которое используется по всей структуре. Компонент обеспечивает доступ к данным для просмотра, отбора, записи. По сути это мост между другими компонентами: «Контроллер» и «Представление».

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

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

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


    Кроме того, «Представление» перехватывает действия пользователей, которые после передаются «Контроллеру». Характерный пример — кнопка, генерируемая «Представлением». Если пользователь её нажимает, в «Контроллере» запускается действие.

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

    Контроллер

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

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

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

    MVC в PHP

    Давайте напишем приложение на PHP с архитектурой MVC. Начнём с примера каркаса:

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

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

    Теперь расширим PHP-пример и покажем, как будем добавлять функционал контроллера, добавляя в приложение взаимодействия:

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

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

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

    Материал подготовлен специально для OTUS на основе статьи «The MVC Pattern and PHP. Part 1».

    Model в MVC на PHP

    Welcome to the PHP MVC framework

    This is a simple MVC framework for building web applications in PHP. It’s free and open-source.

    It was created for the Write PHP like a pro: build an MVC framework from scratch course. The course explains how the framework is put together, building it step-by-step, from scratch. If you’ve taken the course, then you’ll already know how to use it. If not, please follow the instructions below.

    Starting an application using this framework

    1. First, download the framework, either directly or by cloning the repo.
    2. Run composer update to install the project dependencies.
    3. Configure your web server to have the public folder as the web root.
    4. Open App/Config.php and enter your database configuration data.
    5. Create routes, add controllers, views and models.

    See below for more details.

    Configuration settings are stored in the App/Config.php class. Default settings include database connection data and a setting to show or hide error detail. You can access the settings in your code like this: Config::DB_HOST . You can add your own configuration settings in here.

    The Router translates URLs into controllers and actions. Routes are added in the front controller. A sample home route is included that routes to the index action in the Home controller.

    Routes are added with the add method. You can add fixed URL routes, and specify the controller and action, like this:


    Or you can add route variables, like this:

    In addition to the controller and action, you can specify any parameter you like within curly braces, and also specify a custom regular expression for that parameter:

    You can also specify a namespace for the controller:

    Controllers respond to user actions (clicking on a link, submitting a form etc.). Controllers are classes that extend the Core\Controller class.

    Controllers are stored in the App/Controllers folder. A sample Home controller included. Controller classes need to be in the App/Controllers namespace. You can add subdirectories to organise your controllers, so when adding a route for these controllers you need to specify the namespace (see the routing section above).

    Controller classes contain methods that are the actions. To create an action, add the Action suffix to the method name. The sample controller in App/Controllers/Home.php has a sample index action.

    You can access route parameters (for example the id parameter shown in the route examples above) in actions via the $this->route_params property.

    Controllers can have before and after filter methods. These are methods that are called before and after every action method call in a controller. Useful for authentication for example, making sure that a user is logged in before letting them execute an action. Optionally add a before filter to a controller like this:

    To stop the originally called action from executing, return false from the before filter method. An after filter is added like this:

    Views are used to display information (normally HTML). View files go in the App/Views folder. Views can be in one of two formats: standard PHP, but with just enough PHP to show the data. No database access or anything like that should occur in a view file. You can render a standard PHP view in a controller, optionally passing in variables, like this:

    The second format uses the Twig templating engine. Using Twig allows you to have simpler, safer templates that can take advantage of things like template inheritance. You can render a Twig template like this:

    A sample Twig template is included in App/Views/Home/index.html that inherits from the base template in App/Views/base.html.

    Models are used to get and store data in your application. They know nothing about how this data is to be presented in the views. Models extend the Core\Model class and use PDO to access the database. They’re stored in the App/Models folder. A sample user model class is included in App/Models/User.php. You can get the PDO database connection instance like this:

    If the SHOW_ERRORS configuration setting is set to true , full error detail will be shown in the browser if an error or exception occurs. If it’s set to false , a generic message will be shown using the App/Views/404.html or App/Views/500.html views, depending on the error.

    Web server configuration

    Pretty URLs are enabled using web server rewrite rules. An .htaccess file is included in the public folder. Equivalent nginx configuration is in the nginx-configuration.txt file.

    Signup for the course here and understand how this framework is built from scratch, putting it all together step by step.

    Почему отдельно модель и контроллер в MVC?

    Я пытаюсь понять шаблон MVC в Phalcon.

    В моем текущем приложении мне нужно только ОДИН файл шаблона для каждой таблицы. Шаблон содержит сетку данных, оператор SQL для SELECT, форму, кнопки добавления / редактирования / удаления, поле поиска и все, что необходимо для взаимодействия с базой данных, например информацию о соединении (конечно, использование включает в себя как можно больше предотвратить дублирование кода). (Я написал свою собственную сложную среду, которая преобразует xml-шаблоны в полноценную HTML-страницу, включая весь сгенерированный Javascript-код и CSS, без какого-либо PHP, необходимого для бизнес-логики. Вместо того, чтобы иметь конкретные классы PHP для каждой таблицы в базе данных Я использую только стандартные сценарии операций и базы данных, которые могут делать все). Я пытаюсь больше соответствовать веб-стандартам, поэтому я изучаю альтернативы.

    Я попробовал пример Phalcon в INVO и заметил, что для страницы «Компании» нужна модель «Компании», «CompaniesController», «CompaniesForm» и 4 разных представления. Для меня, по сравнению с моим единственным файловым шаблоном сейчас, слишком много разных файлов слишком запутанно.

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

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

    • Если я решу не использовать отдельные классы моделей и контроллеров,
      какие проблемы я мог ожидать?

    Решение

    Phalcon-х Phalcon\Mvc\Model Класс, который ваши модели должны расширять, предназначен для обеспечения объектно-ориентированного способа взаимодействия с базой данных. Например, если ваша таблица Shopping_Cart тогда вы бы назвали свой класс ShoppingCart , Если в вашей таблице есть столбец «id», то вы должны определить свойство в своем классе public $id; ,

    Phalcon также дает вам такие методы, как initialize() а также beforeValidationOnCreate() , Я признаю, что эти методы могут быть очень запутанными в отношении того, как они работают и когда они запускаются, и почему вы когда-нибудь захотите вызвать их в первую очередь.

    initialize() довольно понятен и вызывается всякий раз, когда ваш класс начинается. Здесь вы можете делать такие вещи, как setSource если ваша таблица названа иначе, чем ваш класс или вызовите методы, такие как belongsTo а также hasMany определить его связь с другими таблицами.

    Взаимоотношения полезны, так как это упрощает поиск товаров в корзине пользователя, а затем, используя идентификатор, вы получите ссылку на Accounts стол и, наконец, захватить имя пользователя продавца предмета в корзине покупателя.

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


    С точки зрения смысла определения выделенной модели для каждой таблицы в базе данных, вы можете определить свои собственные пользовательские методы для управления моделью. Например, вы можете определить public function updateItemsInCart($productId,$quantity) метод в вашем классе ShoppingCart. Тогда идея заключается в том, что когда вам нужно взаимодействовать с ShoppingCart, вы просто вызываете этот метод и позволяете модели беспокоиться о бизнес-логике. Это вместо того, чтобы писать какие-то сложные update запрос, который также будет работать.

    Мастер Йода рекомендует:  Будь как кот, вылижи свой код 8 хороших практик по повышению качества кода

    Да, вы можете поместить такие вещи в свой контроллер. Но есть и принцип СУХОЙ (не повторяйся). Целью MVC является разделение интересов. Так зачем в первую очередь следовать MVC, если вам не нужен отдельный раздел «Модели»? Ну, может быть, вам не нужен. Не каждое приложение требует модели. Например, этот код не использует: https://github.com/phalcon/blog

    Лично после некоторого использования структуры моделей Phalcon я начал не любить их одноуровневый подход к моделям. Я предпочитаю многоуровневые модели больше в отношении сущностей, сервисов и репозиториев. Вы можете найти такой код здесь:
    https://github.com/phalcon/mvc/tree/master/multiple-service-layer-model/apps/models
    Но из-за использования слишком большого количества абстракций они могут стать слишком быстрыми и сложными в управлении. Решение где-то между ними обычно выполнимо.

    Но, честно говоря, нет ничего плохого в использовании встроенного адаптера базы данных Phalcon для ваших запросов. Если вы сталкиваетесь с вопросом, который очень трудно написать, никто не сказал, что каждая ваша модель должна расширяться Phalcon\Mvc\Model , Это все еще совершенно логичная логика, чтобы написать что-то вроде:

    Модели очень гибкие, нет «лучшего» способа их расставить. Подход «все работает» — это хорошо. А также: «Я хочу, чтобы у моих моделей был метод для каждой операции, которую я когда-либо мог хотеть».

    Я признаю, что INVO а также vokuro Полуфункциональные примеры (построенные только для демонстрационных целей) не так хороши для выбора хороших навыков проектирования моделей. Я бы посоветовал найти часть программного обеспечения, которая на самом деле используется серьезно, например, код для форумов: https://github.com/phalcon/forum/tree/master/app/models

    Phalcon — все еще довольно новая структура для поиска хороших образцов для подражания.

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

    Как вы говорите, разделение интересов не так важно для вас в небольшой команде, так что вы можете обойтись без каталога моделей. Если это поможет, вы можете использовать что-то вроде того, что я написал для вашего адаптера базы данных: http://pastie.org/10631358
    тогда вы бы выбросили это в каталог app / library. Загрузите компонент в вашей конфигурации следующим образом:

    Затем в вашей базовой модели вы бы добавили:

    Наконец, из модели вы можете сделать что-то простое:

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

    Есть и другие способы сделать это. Надеюсь, мой компонент «EasySQL» приблизит вас к вашей цели. В зависимости от ваших потребностей, может быть, мой компонент «EasySQL» — это только долгий путь написания:

    Если нет, возможно, вы ищете что-то еще в направлении

    Другие решения

    Модель, представление и контроллер были разработаны для разделения каждого процесса.

    Такой подход используется не только в Phalcon, но и в PHP сегодня.

    Модель должна быть тем местом, где вы сохраняете или обновляете вещи, она не должна полагаться на другие компоненты, а на саму таблицу базы данных (ТОЛЬКО!), И вы просто передаете некоторую логическую (если CRUD выполняется) или запись базы данных запрос.

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

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

    Мы сократили слово M-V-C, но на самом деле мы обрабатываем это:

    Запрос HTTP -> Службы загружены (включая обработчики ошибок) -> Маршрутизатор -> (Анализатор маршрутов) -> (Отправка на указанный контроллер) -> Контроллер -> (Ответ с использованием JSON или адаптера шаблона | Вызов модели | Вызов ACL | Call Event | Queue | API Request | etc ….) -> end.

    Архитектурный паттерн MVC

    По всему интернет-миру разбросаны миллионы веб-приложений. Есть совсем простые, есть такие, что сам «архитектор матрицы ногу сломит». Но их объединяет одно — MVC.

    Самый популярный архитектурный паттерн в мире среди веб-приложений — модель-представление-контроллер (Model View Controller или просто MVC). Впервые, он был использован ещё в конце 70-х двадцатого века, в приложениях на языке Smalltalk. А затем, его приютили программисты Java и расшарили для всего мира и всех языков программирования. PHP не стал исключением. Сегодня, только малая часть программистов, коллекционирующих раритетный PHP-код может себе позволить не смотреть в сторону MVC.

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

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

    Программное обеспечение или ресурс Требуемая версия
    Denwer (PHP5.3) 3 +
    Notepad, или любой текстовый редактор
    Mozilla Firefox 3.6 +

    Примечания:

    • Мы предполагаем, что у вас есть базовые знания PHP.


    Паттерн MVC

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

    • Модель отвечает за управление данными, она сохраняет и извлекает сущности, используемые приложением, как правило, из базы данных и содержит логику, реализованную в приложении.
    • Представление несет ответственность за отображение данных, которые даёт контроллер. С представлением тесно связано понятие шаблона, который позволяет менять внешний вид показываемой информации. В веб-приложении представление часто реализуется в виде HTML-страницы.
    • Контроллер связывает модель и представление. Он получает запрос от клиента, анализирует его параметры и обращается к модели для выполнения операций над данными запроса. От модели поступают уже скомпонованные объекты. Затем они перенаправляются в представление, которое передаёт сформированную страницу контроллеру, а он, в свою очередь, отправляет её клиенту.

    Схематично потоки данных в этой модели можно представить так:

    Вход в реальность

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

    Мы не будем сейчас рассматривать архитектуру всей социальной сети. Мы возьмём только маленькую подзадачку, представим всю её серьёзность и применим к ней паттерн MVC.

    Как только мы начинаем его использовать, то сразу задумываемся — а как бы нам расположить скрипты нашего решения так, что бы всё было под рукой? Для этого, разместим каждый из трёх разделов нашей MVC-системы по отдельным папкам и, таким образом, получим простую структуру каталогов, в которой легко найти то, что нам нужно. Кроме того, эти три папки поместим в каталог lib, и вынесем его выше корневого веб-каталога www:

    Вынесение каталога lib (содержащего движок нашего сайта) из веб-каталога даёт нам бОльшую защищённость, делая нашу систему недоступной для посягательств шаловливых ручонок взломщиков.

    Контроллер

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

    В нашем простом примере, контроллер будет сконцентрирован в одном классе FrendCnt . Подробнее его опишем позже.А сейчас немного о точке входа в веб-приложение — это, конечно, будет файл index.php. В нём, мы определим точку отсчёта для подключения наших скриптов. Создадим экземпляр контроллера, и вызовем у него метод, который начнёт обрабатывать HTTP-запрос и определит что делать дальше.

    Листинг №1 (файл index.php):

    Теперь о контроллере. У нас — это класс FriendCnt . Вы уже заметили, что экземпляр этого класса создаётся в index.php. Он имеет только один метод invoke() , который вызывается сразу после создания экземпляра. В конструкторе контроллера, создаётся объект на основе класса модели — FrendList (список друзей) для оперирования с данными.

    В функции invoke() , на основе пришедшего HTTP-запроса, принимается решение: какие данные потребуются от модели. Затем происходит вызов метода извлекающего данные. Далее происходит подключение шаблонов для отображения, которым передаются данные из контроллера. Обратите внимание, что контроллер ничего не знает о базе данных или о том, как страница генерится.

    Листинг №2 (файл контроллера FriendCnt.php):

    Модель и сущности

    Модель — это образ реальности, из которой взято только то, что нужно для решения задачи. Модель концентрируется на логике решения основной задачи. Многие называют это бизнес-логикой, на ней лежит большая ответственность:

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

    У нас к модели относятся два скрипта, в каждом из которых определён свой класс. Центральный класс FriendList и класс-сущность Friend . В центральном классе, происходит манипуляция с данными: получение данных от контроллера и их обработка. Класс-сущность служит контейнером для переноса данных между моделью и представлением, а также определяет их формат. При хорошей реализации паттерна MVC, классы сущности не должны упоминаться в контроллере, и они не должны содержать какую-либо бизнес-логику. Их цель — только хранение данных.
    В классе FriendList , работающем со списком друзей, мы создали функцию, которая моделирует взаимодействие этого класса с базой данных. Метод getFriendList() возвращает массив из объектов, созданных на основе класса Friend . Для обеспечения удобства работы с данными, также была создана функция, индексирующая массив объектов. Контроллеру оказались доступны только два метода: setKey() — устанавливает поле ключа, по которому возвращаются детальные данные о друге; fetch() — возвращает или конкретный объект или весь список друзей.

    Листинг №3 (файл модели FriendList.php):

    В зависимости от реализации объектов Сущности, данные о ней, могут быть оформлены в виде XML-документа или JSON-объекта.

    Листинг №4 (файл сущности Friend.php):

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

    Теперь нам нужно представить данные в наилучшем свете для пользователя.

    Настал черёд поговорить о Представлении. В зависимости от задачи, данные могут быть переданы представлению в разных форматах: простые объекты, XML-документы, JSON-объекты и т.д. В нашем случае передаётся объект или массив объектов. При это мы не побеспокоились о выводе базового слоя — то, что относится к футеру и хедеру генерируемой страницы, этот код повторяется в обоих файлах представления. Но для нашего небольшого примера это не важно.

    Главное здесь показать, что представление отделено от контроллера и модели. При этом контроллер занимается передачей данных от модели к представлению.

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

    Листинг №5 (файл для вывода списка друзей friendlist.php):

    Листинг №6 (файл для вывода списка друзей friendone.php):

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

    Мы могли бы реализовать детальный просмотр с помощью AJAX, тогда бы у нас была всего одна страница, и мы формировали бы часть представления через JSON-объекты непосредственно на компьютерах клиентов. Существует куча вариантов на этот счёт.

    Это упрощённый пример веб-приложения на основе паттерна MVC. Но уже на нём можно увидеть массу возможностей. К плюсам мы уже отнесли гибкость и масштабируемость. Дополнительными плюсами будут — возможности стандартизации кодирования, лёгкость обнаружения и исправления ошибок, быстрое вхождение в проект новых разработчиков. Кроме того, вы можете в своём приложении изменять способ хранения сущностей, используя для этого сторонние веб-сервисы и облачные базы данных. Из минусов можно привести только небольшое увеличение объёма скриптов. А так, сплошные плюсы. Так-что пользуетесь на здоровье.

    Здесь лежат файлы проекта, качайте сравнивайте:

    Ну как? Какие мысли? Комментируем, не стесняемся.

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