Пишем PHP фреймворк, модель MVC (4%)

13 комментариев

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

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

Теория

Итак что такое MVC?
MVC это вид архитектуры в которой приложение разделено на три основных компонента:

  • Model — отвечает за непосредственные алгоритмы, расчёты и тому подобное внутреннее устройство системы.
  • View — отвечает за отображение информации, поступающей из системы или в систему.
  • Controller — является связующим звеном между «представлением» и «моделью» системы, посредством которого и существует возможность произвести разделение между ними. Контроллер получает данные от пользователя и передаёт их в «модель». Кроме того, он получает сообщения от модели, и передаёт их в «представление».

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

Наш фреймворк

Скачал программку специальную  «Diagram Designer» чтоб схемку нарисовать. Пару часов еб… мучался, рисовал. И каково же было мое удивление когда я, почти закончив, обнаружил, что это был триал проги, и в триале стоит ограничение на максимальное количество созданных объектов…. Как так… И не сохранить нормально и не доделать… Вообщем сделал пару принтскринов вставил в паинт и дорисовал уже там. Но блин обидно, неужели нельзя было сразу предупредить о том что прога — триал и с такими злыми ограничениями.

Вообщем вот схема, которую я набросал, с архитектурой нашего будущего фреймворка:

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

Что содержит эта схема:

  • Dispatcher — основной класс/ядро системы, будет запускать контроллер, передавать необходимые параметры в контроллер и на выходе рендерить готовое представление в браузер пользователю
  • Router — та хрень/часть кода/класс/etc которая будет определять какой именно контроллер необходимо запустить
  • Controller — action-ы сгруппированные в один модуль по какому либо признаку (например работа с пользователем) будут называться отдельным контроллером
  • Action — некое действие которое захотел выполнить наш юзер в нашем веб приложении (метод контроллера)
  • Драйвер БД — некая библиотека через которую мы будет обращаться к БД (чтобы можно было элементарно сменить тип БД)

Все остальное, надеюсь, понятно.

  1. Trololo

    Хм… Мне начинает нравится этот цикл статей. Чесно говоря, первый раз слышу о понятии MVC, поэтому пожалуй, подпишусь на ваш блог)

    Буду, так сказать, переходить к более соверменному программированию на PHP :)

  2. Василий

    Спасибо! Интересная и наглядная схема! Теперь в голове есть хоть какое то представление об архитектуре MVC

      1. Дмитрий Амиров Автор

        Будет. Но думаю где то через месяц. Сейчас занят другим проектом =(

  3. Leon

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

    А как по мне как раз в вебе она самая идиотская и неудобная. Имеется ввиду конечно не сама идея, а паттерн на котором норовят городить фреймворки (включая текущую статью).

    Кроме того, он получает сообщения от модели, и передаёт их в «представление».

    Чушь. Представление рендерит страницу и лучше знает какие данные ему для этого нужны. Зачем нужен контроллер как тупой посредник? Контроллер может только запустить нужное представление а оно само уже запросит данные у модели.
    И что сие такое «сообщения» от модели?
    Дико извиняюсь, но чтобы писать подобные статьи нужно набраться знаний и опыта. Умения рисовать красивые кубики тут недостаточно.

    1. Дмитрий Амиров Автор

      А как по мне как раз в вебе она самая идиотская и неудобная.

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

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

      Спасибо за критику, едко но верно. На самом деле вы абсолютно правы. Я тоже понял что соответствующих знаний и опыта у меня пока не имеется. Поэтому пока эту идею оставил на будущее…

      1. Skif_ru23

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

        Ребята, для начала стоит разобраться, какая из схем потерна используется… Хуже всего если Леон нахватался вершков и выступил с критикой… MVC как патерн не есть именно такой подход, схем много, например из диспетчера запрос может придти в Представление, далее Контроллер, потом Модель, т.е. отработать последовательно от Вида, может как говорит Леон, Контроллер запускает Вид, который сам уже запускает Модель… Здесь схема другая, всем управляет контроллер… Так что не лезте, а учите матчасть… Чего ерепениться и мешать другим… Интелект, давай продолжение… Новичков много им нужна инфа для мозговарения, жизнь сама расставит все по местам…

        1. Дмитрий Амиров Автор

          Спасибо за поддержку, но все же, как я уже говорил выше, я понял что у меня недостаточно опыта для такого рода статей. В будущем (через год где то) может и выйдет продолжение, но не сейчас это точно…

  4. ESCAPE

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

  5. Mavr

    Жаль тема умерла. Вот по картинке не совсем понял роль диспетчера. Рутер запускает нужный контроллер и в нём нужный экшн, как то так. А что делает диспетчер?

    1. Дмитрий Амиров Автор

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

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

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

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