gzhegow
@gzhegow
Думал, стану умнее, когда адаптируюсь, но нет

А как выглядит ваш MVC?

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

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

2а. Есть конфиги компонентов (папка config) - обычные пхп файлы - массивы с ключами-значениями

2б. Есть "компоненты" (папка core) - это классы фреймворка, подключаются в главном файле, это например:
App() - содержит методы работы с путями, методы ошибки и логов, методы подключение скриптов и стилей с минификацией
Loader() - позволяет загружать все методом this->load->model(), this->load->controller() и тд
Router() - из конфига по регулярке ищет совпадение на REQUEST_URI и запускает "вьюху"
Db() - соединяется к бд и хранит PDO
Identity() - авторизация, регистрация, хранение данных сессий в БД и их восстановление

3. Есть "вьюхи" (папка views) - я почему то их воспринял, как основные скрипты страницы - то есть роутер отсылает прямо на вьюху, а уже она подключает контроллеры и шаблон - представляют собой классы, где автоматически вызывается метод index(). Из видимых отличий от контроллеров - в индексы иногда передаю данные, например при вызове $this->app->error() вызывается "вьюха" index с данными о текущей ошибке. В контроллеры передачи данных пока не было, но скорее всего будет, чтобы экономить запросы, то есть вообще под вопросом отличие "вьюхи" от "контроллера"

4. Есть "контроллеры" (папка controllers) это модули самого проекта - хедер, футер, меню, что-угодно, представляют собой классы, где автоматически вызывается метод index(), остальные - по желанию в самом index() но их как правило нет

5. Есть "модели" (папка models) - классы, в которых в методах делаются запросы в БД или в файлы с данными, или на сторонние сервисы - я, правда, читал про какую-то там "бизнес-логику", но я как слышу слово бизнес, я говорю "оооо не, спасибо, бизнеса мы уже нажрались, оставьте себе" и эти умные слова не воспринимаю

6. Есть "темплейты" (папка templates) - по сути просто файлики с версткой и php-кодом в таком минимуме как только можно - то есть да, там встречаются echo, if, foreach, иногда счетчики, в некотором случае рекурсии при выводе деревьев, но там не подключаются модули, модели и тп - исключительно форматирование вывода. Бывают трех видов - pages/layouts/modules.
pages - страницы, тот самый "двух-колоночный макет", "трех-колоночный макет" и тд
layouts - обертки - либо html с meta(), либо просто , если ajax запрос
modules - кусочки верстки для контроллеров - менюшки, хедеры, футеры, что угодно

7. Планируется ввод "languages" - файликов массив-значение, которые можно подключать один за другим. Соответственно будет компонент "language" который разбирает url, но скорее просто допишу Router()

==================
ДОБАВЛЕНО 05.01.2017
1. По советам бойцов роутер стал вести на контроллеры как общепринято, а View - подбирать шаблон из папки templates и тему отображения страницы, тем самым из контроллеров исчез код глобальных скриптов, хедера,футера и тд - применение View-хам нашлось.

2. Предположительно в именитых фреймворках контроллеры не просто так сделаны безымянными функциями. Если вдруг понадобилось перенести контроллеры из одной папки в другую - то подход с неймспейсами или длинными именами классов так или иначе заставит классы переименовывать. Если контроллеров тысячи 2 - работы часа на 4 вам обеспечено. Если контроллеры - безымянки - переименовывать не надо - знай себе перенес и дело с концом. Прикол в том, что безымянка - это функция, тогда как класс это таки класс. В классе есть доступ к слову $this и можно навешать кучу разных штук из главного класса. А к безымянке такого не подцепишь, разве что передашь $app в качестве параметра и будешь от нее скакать, не слишком удобно. Надо подумать, возможно было бы удобно работать не с безымянной функцией, а с т.н. безымянным классом StdClass, который наворачивать методами, как и обычный класс. Таким образом файл будет лежать в папке как нравится, а работать будет как навороченный StdClass и имя класса как таковое будет не нужно вообще и в то же время это будет обьект с собственной областью видимости

Кто-то может прокомментировать или добавить?
  • Вопрос задан
  • 1863 просмотра
Решения вопроса 1
@ckr
А у меня все просто. Я не отхожу дальше одного файла от инструкций в мануале.
В лучших традициях express. Конечно, это не PHP, но посмотрите сюда:
expressjs.com/ru/guide/routing.html
Может, Вам тоже понравится :-)

Чуть не забыл, для вьюх использую jade
Ответ написан
Пригласить эксперта
Ответы на вопрос 8
Sanasol
@Sanasol Куратор тега PHP
нельзя просто так взять и загуглить ошибку
2б. Есть "компоненты" (папка core)

Это должен быть composer

Router() - из конфига по регулярке ищет совпадение на REQUEST_URI и запускает "вьюху"

4. Есть "контроллеры" (папка controllers) это модули самого проекта - хедер, футер, меню

шта.
Роутер пинает контроллер и его методы в зависимости от роута.
А контроллер уже работает с моделями и выводит результат через view.
Сейчас у вас контроллеры вообще просто для того чтобы они были получается...

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

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

базнес-логика это непосредственно логика вашего проекта, а не внутренние процессы фреймворка и т.п.
Ответ написан
customtema
@customtema
arint.ru
Не надо называть отображения "вьюхами".

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

Общий ответ на ваш вопрос - посмотрите, как у других сделано. Для изучения доступны исходные коды массы свободных проектов.
Ответ написан
banderos120
@banderos120
Играю на балалайке
Вы тут описываете вариант конкретной реализации. Вы можете придерживаться MVC и через три файла и через один файл, главное логически разделять код на составляющие, каждая из которых будет инкапсулировать в себе определенный тип работы - с представлением, с передачей данных, с обработкой данных.
Ответ написан
za4me
@za4me
Человек
Насчет MVC есть же отличная и понятная статья на хабре, первая ссылка в поиске по запросу "mvc habrahabr".
Ответ написан
Комментировать
riky
@riky
Laravel
почитал некоторые ваши комменты, понял ваш контекст.
даже молодость свою вспомнил, и сам раньше свой фрейм писал, думая что мой фрейм на пару-тройку десятков классов минималистичный, простой и быстрый. писать свое это круто поднимает скил, плюс ты знаешь его от а до я, если нужно что-то добавить или поменять.

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

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

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

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

если уж собрались пилить свой, то порекомендую хотя бы начать использовать готовые качественные компонеты. когда лет 5 назад пилил свой фреймворк сначала писал все с нуля потом начал внедрять симфони компоненты symfony.com/components а потом и вовсе на симфони фулл стек перешел.
там их много, хватит на долго, рекомендую для начала посмотреть эти:
HttpFoundation
HttpKernel
DependencyInjection <-- очень очень маст хэв сразу с этим разобраться, жаль я поздно начал применять
Form
Routing
и Twig (шаблонизатор, он отдельно идет)

во вторую очередь
EventDispatcher
Console
Config

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

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

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

сорри за много букв и чрезмерный "позитив" просто сам когда то переболел.
Ответ написан
@g00d
у тебя два путя (с) :-)
либо ты берешь известный фрейм и начинаешь пилить вместе с ним, параллельно изучая что да как.
либо ты берешь и начинаешь читать о DDD и открывая чакры понимаешь что фреймы все это "от лукавого", единственное что тебе надо это решить конкретную проблему, выделить слой бизнесс логики, применить известную архиктуру типа гексагона и все.

P.S. ах да, есть еще один вариант, нынче модно в функциональщину рвануть, тоже вариант!
Ответ написан
@dev400
Контроллеры принимают реквест и дергают нужный сервис, затем делают рендер.
Ответ написан
@caballero
Программист
Никак не выглядит потому что MVC в вебе - как на корове седло (многочисленные вопросы на форумах как же этот эмвэцэ соорудить это только подтверждают).
Предпочинаю более естественные компонентные решения.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы