Сейчас проект Lev успешно прошел стадию проверки идеи, что сайт и движок могут быть физически разделены. Он полностью функционален, но нет документации, осталось много хвостов от его прародителя Grav. В частности, как вы заметили, в вендорах остался grav, который первое время реально был вендором, но по мере разработки архитектура изменилась радикально, grav уже давно не вендор, но пока его оставляем типа на всякий. Однозначно уберем. Но благодарны Grav останемся.
Насчет зарубежных библиотек — согласитесь, они не совсем зарубежные. Вы же сами пишете, что много российских комитов...
Сайт — это фронтенд, движок — это не только система кэширования, а весь бэкенд.
Класс Site нужен для инкапсуляции всех свойств и методов объекта сайт. Объект Site есть на экране браузера, но его почему-то нет в фреймворках. В нынешних фреймворках свойства и методы сайта распылены по разным конфигам и классам. Это результат (вполне естественный) первого этапа развития сайтостроения, когда отрабатывались подходы к управлению одним сайтом. Вроде отработали...
Проект Lev говорит простые вещи: сайт есть самостоятельная сущность, сайт и движок — разные сущности. Давайте это осознаем и разделим их. Как то так...
Народ!!! Прошу внимания::: Мы здесь обсуждаем не сервисные слои приложения (pipes, middleware), а MVC. Если вы под «сервисным слоем» понимаете Сценарий (цепочку преобразователей запроса в ответ), то это некорректно. Дело в том, что модуль MVC скорее относится к ядру приложения (выше кто-то отнес к UI, я почти согласен), а не к сервисам. Да, в MVC есть цепочка преобразования (как минимум Модель-Представление), да, она может напоминать пайплайн или оболочки сервисов. Но это только напоминание.
Мы здесь обсуждаем не сервисные слои приложения (pipes, middleware), а MVC. Если вы под «сервисным слоем» понимаете Сценарий (цепочку преобразователей запроса в ответ), то это некорректно. Дело в том, что модуль MVC скорее относится к ядру приложения, а не к сервисам. Да, в MVC есть цепочка преобразования (как минимум Модель-Представление), да, она может напоминать пайплайн или оболочки сервисов. Но это только напоминание.
Мы здесь обсуждаем не сервисные слои приложения (pipes, middleware), а MVC. Если вы под «сервисным слоем» понимаете Сценарий (цепочку преобразователей запроса в ответ), то это некорректно. Дело в том, что модуль MVC скорее относится к ядру приложения, а не к сервисам. Да, в MVC есть цепочка преобразования (как минимум Модель-Представление), да, она может напоминать пайплайн или оболочки сервисов. Но это только напоминание.
Согласен. С одним замечанием. Сейчас просто нет еще согласия насчет есть ли этот сервисный слой, если есть — то каков он и т.д. Все на уровне обсуждения.
Целью было не изобретать новый паттерн, а подкрутить MVC под имеющуюся проблему. Насчет наличия проблемы согласие есть, насчет ее разрешения согласия нет. Мое предложение простое: Model-View — это цепочка преобразователей, которая может быть расщеплена, не нарушая самой концепции MVC.
Совершенно верно. Все так. Включая и то, что модель или представление могут отсутствовать в каких-то крайних ситуациях. Или даже могут отсутствовать оба.
Проблема принципиальная. У вас в контроллере сидит модель:
return view('info', ['name' => $user->getFullName()]);
Вам придется переписывать контроллер всякий раз, когда меняется представление, скажем, вместо полного имени захочется просто имя.
Лучше полная независимость контроллера от моделей и представлений, согласитесь. Контроллер тогда просто вызывает нужные для запроса модели и представления (это делается в роутере). И контроллера как-бы вообще нет. Он есть, конечно. Но вся специфика приложения строго в модели.
Вам так господин Тейлор сказал? То, что в доке приведены самые простые примеры уже обсуждалось не раз. В доке городить сервисный слой оверхед, она решает другую задачу. А вот в проекте больше шести человеко-месяцев выделить бизнес логику в отдельный слой уже необходимость.
Насчет условий — вы прям в точку попали. Что делать с ветвлениями, циклами, — мне пока неясно.
Сам я пока условия и редиректы пишу в одном действии. Я понимаю, что это вне концепции. Пока я вижу только одно решение условий — некий условный ветвитель, который переключает разные сценарии. Сценарии в смысле этой статьи — последовательность действий по преобразованию запроса в ответ.
Буду признателен любым предложениям как можно условия вписать в цепь Модель-Представление.
Вы правы по большому счету во всем.
Сейчас проект Lev успешно прошел стадию проверки идеи, что сайт и движок могут быть физически разделены. Он полностью функционален, но нет документации, осталось много хвостов от его прародителя Grav. В частности, как вы заметили, в вендорах остался grav, который первое время реально был вендором, но по мере разработки архитектура изменилась радикально, grav уже давно не вендор, но пока его оставляем типа на всякий. Однозначно уберем. Но благодарны Grav останемся.
Насчет зарубежных библиотек — согласитесь, они не совсем зарубежные. Вы же сами пишете, что много российских комитов...
Сайт — это фронтенд, движок — это не только система кэширования, а весь бэкенд.
Класс Site нужен для инкапсуляции всех свойств и методов объекта сайт. Объект Site есть на экране браузера, но его почему-то нет в фреймворках. В нынешних фреймворках свойства и методы сайта распылены по разным конфигам и классам. Это результат (вполне естественный) первого этапа развития сайтостроения, когда отрабатывались подходы к управлению одним сайтом. Вроде отработали...
Проект Lev говорит простые вещи: сайт есть самостоятельная сущность, сайт и движок — разные сущности. Давайте это осознаем и разделим их. Как то так...
Спасибо, @gr33tx!У тебя карма тоже не блестит, вижу. Молодец!
Сервера имеют имена, в Винде буковки с:/, d:/, … Вам лучше обратиться к своему саппорту.
В чем-то вы правы. Первое время Grav был вендором Lev. Затем решили от этого отказаться. Grav сейчас не вендор, а предшественник. Из вендоров уберем.
Мы здесь обсуждаем не сервисные слои приложения (pipes, middleware), а MVC. Если вы под «сервисным слоем» понимаете Сценарий (цепочку преобразователей запроса в ответ), то это некорректно. Дело в том, что модуль MVC скорее относится к ядру приложения (выше кто-то отнес к UI, я почти согласен), а не к сервисам. Да, в MVC есть цепочка преобразования (как минимум Модель-Представление), да, она может напоминать пайплайн или оболочки сервисов. Но это только напоминание.
Тыкаю: в конце обсуждения пост от ConnorVG commented on Apr 12 2017.
Во всех ваших примерах этот принцип нарушен.
return view('info', ['name' => $user->getFullName()]);
Вам придется переписывать контроллер всякий раз, когда меняется представление, скажем, вместо полного имени захочется просто имя.
Лучше полная независимость контроллера от моделей и представлений, согласитесь. Контроллер тогда просто вызывает нужные для запроса модели и представления (это делается в роутере). И контроллера как-бы вообще нет. Он есть, конечно. Но вся специфика приложения строго в модели.
Это тоже обсуждалось: github.com/laravel/framework/issues/18786
Уточнить можете? Или вы про то, что в фреймворке можете сами все сделать. Если про это, то ответ один: PHP — лучший фреймворк.
Насчет условий — вы прям в точку попали. Что делать с ветвлениями, циклами, — мне пока неясно.
Сам я пока условия и редиректы пишу в одном действии. Я понимаю, что это вне концепции. Пока я вижу только одно решение условий — некий условный ветвитель, который переключает разные сценарии. Сценарии в смысле этой статьи — последовательность действий по преобразованию запроса в ответ.
Буду признателен любым предложениям как можно условия вписать в цепь Модель-Представление.