Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 156
Моё мнение — пора прекращать сочинять велосипеды.
http://cmf.symfony.com/
http://cmf.symfony.com/
К такому мнению разные люди, использующие PHP, переодически приходят уже вот лет 15.
Люди, которые разрабатывают сайты-сервисы, CRM, ecommerce и т.п. придут к такому мнению, и они косо смотрят на людей, которым нужна нормальная админка (не сгенерируемая и не «готовый бандл»), т.к. для них это первично. Красивый код нужен, расширяемость и поддерживаемость нужна, нужен удобный роутер и класс генерации SQL. Для них админка на маркдауне — это нормально.
Люди, которые разрабатывают сайты-визитки, каталоги и блоги, не придут к такому мнению и косо смотрят на людей, которым нужен MVC, но которые считают позволительным дать админу (а это может быть секретарша фирмы по продаже железобетона) редактировать текст страницы в маркдауне и конфиг в json. Важна автообрезка фотографий и их загрузка, важен вузивиг.
Нельзя путать CMF/фреймворки и CMS — разные кейсы, разные люди. Одни считают что, любой сайт можно сделать на Yii/Symphony (а других они и не делают), другие считают, что важно писать мало кода и быстро стартовать проект, и чтобы перетаскиванием картинка вставлялась в новость, и этого не надо было программировать. Обе группы косо друг на друга смотрят и не понимают друг друга.
В конце концов, тот же новый lumen от Laravel — тоже велосипед в каком то роде.
Люди, которые разрабатывают сайты-визитки, каталоги и блоги, не придут к такому мнению и косо смотрят на людей, которым нужен MVC, но которые считают позволительным дать админу (а это может быть секретарша фирмы по продаже железобетона) редактировать текст страницы в маркдауне и конфиг в json. Важна автообрезка фотографий и их загрузка, важен вузивиг.
Нельзя путать CMF/фреймворки и CMS — разные кейсы, разные люди. Одни считают что, любой сайт можно сделать на Yii/Symphony (а других они и не делают), другие считают, что важно писать мало кода и быстро стартовать проект, и чтобы перетаскиванием картинка вставлялась в новость, и этого не надо было программировать. Обе группы косо друг на друга смотрят и не понимают друг друга.
В конце концов, тот же новый lumen от Laravel — тоже велосипед в каком то роде.
редактировать текст страницы в маркдауне
И что в этом плохого? Если речь идет о лэндингах, то это очень даже удобно. Я когда-то сильно в этом сомневался но после того как впилил управление контентом на markdown на нескольких проектах и наблюдал как с этим делом работают контент менеджеры — им нравилось. Работали с системами девочки не сильно шарящие во всяких там делах.
Конфиги в json это да, это плохо. Ну и я тоже не фанат автосгенерированных админок, гридов и тупых крудов которые делают большинство.
новый lumen от Laravel — тоже велосипед
Нет, нынче фреймворки это не монолитный трешь а набор компонентов. Lumen это просто другой набор компонентов, чуть более легковестных. Например там заменили мощьный и гибкий (а так же медленный) symfony/routing на fastroute от ника. Вот и все отличия. Не велосипеды, просто пак библиотек.
К слову о библиотеках. Буквально сегодня искал возможность быстро организовать CMS функциональность для проекта. И это либо были CMS-ки расчитанные на использование оных как основы для проекта, либо недобиблиотеки с убогими админками. И вот это расстраивает. В то же время можно было бы сделать удобный компонент для управления контентом который не завязан на все эти убогие инфраструктуры хаков и плагинов, который можно расширять декорацией и композицией классов и т.д.
Symfony от Sensiolabs я использовал в реальных проектах не один раз. Задача стоит не такая. Да и идея совсем не та. Symfony настоящий Framework on PHP. Но никак не готовая CMS. Я хочу написать «валидную» с точки зрения разработки и масштабируемости систему, которой сможет пользоваться даже дедушка.
Понимаете ли, взяв к примеру WordPress, DLE или прочие CMS, мы получим практически идеальную с точки зрения конечного пользователя (не отходящего за рамки возможностей) систему для администрирования блога или новостной ленты. Но также есть масса потребностей и спроса на хорошо поддерживаемую и понятную со всех сторон систему, которая предоставит удобный интерфейс как для пользователя так и для разработчика.
Работая в компании на протяжении последних нескольких лет, становится ясно чего хочет заказчик. Но увы, редко попадаются командные проекты чтобы начать писать что-то стоящее. И я не желаю тратить время на холивар о том, как много уже написано и «не пиши велосипеды». Все это уместно в конкретных ситуациях. Но если заказчик не из «нашего мира», и захочет магазин на WP, то и альтернатива для него в виде OpenCart к примеру, будет неуместна.
В данной ситуации, моя задача узнать какой максимально понятный програмный интерфейс для масштабируемости выбрать для своей CMS. Заметьте, что я ничего не пытаюсь вам навязать, продать или прорекламировать. Также вам не удастся отговорить меня воротить такими вещами и изобретать велосипеды. В каждом последующем посту, я буду выкладывать не однозначные задачи по решению конкретных архитектурных и программных вопросов.
З.Ы. Только за сотрудничество!)
Понимаете ли, взяв к примеру WordPress, DLE или прочие CMS, мы получим практически идеальную с точки зрения конечного пользователя (не отходящего за рамки возможностей) систему для администрирования блога или новостной ленты. Но также есть масса потребностей и спроса на хорошо поддерживаемую и понятную со всех сторон систему, которая предоставит удобный интерфейс как для пользователя так и для разработчика.
Работая в компании на протяжении последних нескольких лет, становится ясно чего хочет заказчик. Но увы, редко попадаются командные проекты чтобы начать писать что-то стоящее. И я не желаю тратить время на холивар о том, как много уже написано и «не пиши велосипеды». Все это уместно в конкретных ситуациях. Но если заказчик не из «нашего мира», и захочет магазин на WP, то и альтернатива для него в виде OpenCart к примеру, будет неуместна.
В данной ситуации, моя задача узнать какой максимально понятный програмный интерфейс для масштабируемости выбрать для своей CMS. Заметьте, что я ничего не пытаюсь вам навязать, продать или прорекламировать. Также вам не удастся отговорить меня воротить такими вещами и изобретать велосипеды. В каждом последующем посту, я буду выкладывать не однозначные задачи по решению конкретных архитектурных и программных вопросов.
З.Ы. Только за сотрудничество!)
Но никак не готовая CMS
Все фреймворки это только инфраструктура приложения. CMS обычно — полноценное приложение. Попытки сделать универсальное приложение обречены на провал изначально.
Можно как и в случае фреймворков попытаться обобщить проблемы, разбить все на отдельные компоненты что бы собирать готовую систему из конструктора, но почему-то выходят монолитные и неповоротливые монстры. Причем все хотят сделать универсальную систему, а ее потом интегрировать боль.
систему для администрирования блога или новостной ленты.
А люди потом на этом заказывают интернет магазины и соц сети. И в этом проблема.
становится ясно чего хочет заказчик
Оно всегда понятно, он хочет что бы продукт приносил бабло. Удобство использования со стороны контент менеджера снижает затраты, вот и все.
для своей CMS
Где-то год назад я обдумывал как сделать нашим маркетологам простенькую CMS-ку затратив минимум усилий и с которой им будет удобно работать (не дергать программистов на каждый чих). В итоге, пройдя по граблям, если у меня будет такая задача в будущем я просто возьму любой генератор статический сайтов, настрою CI-ку на билд проекта, сделаю возможность собирать странички из блоков (yaml, markdown + A/B тестирование), напишу простенький web-интерфейс скрывающий работу с git и т.д. и это будет всеравно проще чем писать полноценную CMS с базами данных и т.д. В итоге же под задачи наших маркетологов готовые CMS-ки стали быстро замедлять работу.
я ничего не пытаюсь вам навязать, продать или прорекламировать
ну у вас по сути еще нет продукта. А судя по описанию он так же скорее всего не подойдет под те задачи, которые попадаются мне.
В данной ситуации, моя задача узнать какой максимально понятный програмный интерфейс для масштабируемости выбрать для своей CMS.
Так вроде Unix-философия давным давно ответила на этот вопрос. Гляньте на реализацию модульности в zf2, на мой взгляд это один из хороших примеров.
Нельзя так просто взять и разделить все на Model-View-Controller
Можно.
А то что вы хотите сделать будет HMVC
Действительно можно, тот же yii2 вам в пример с аналогичными «пакетами» (здесь они называются «расширения») — www.yiiframework.com/doc-2.0/guide-structure-extensions.html. Аналогичные подходы есть и в kohana и laravel с пакетными «наборами» и возможностью динамической инициации в роутере.
Если интересно развести холивар на тему, был бы очень рад побеседовать в личке (чтобы не засорять) и выяснить в чем отличия моей идеи и вашего HMVC.
Но по поводу «Можно.» готов спорить прямо здесь. Я очень часто сталкиваюсь с проблемой того, что приложение на MVC/HMVC имеет серьезные проблемы с архитектурой.
Если принять Модель за интерфейс работы с данными, то остается вопрос куда деть интерфейсы для работы с другими интерфейсами (Внешние API к примеру).
Я придерживаюсь правила, что не должно быть функционала больше чем требуется в данный момент. Это делает более трудоемким процесс расширения возможностей общей системы, но никак не сложнее. (OverEngineering — BAD!) Но каждый фреймворк предоставляет нам готовый интерфейс взаимодействия пользователя с данными (в нашем случае WEB), и даже более, что не всегда используется.
Как итог, реализация на Symfony (как фреймворк, он меня вполне устраивает) способов авторизации через соц. сети выливается в ручную установку пакетов, настройку, написания контроллера, функционала менеджера модели пользователя… проблема исчезнет, если функционал для работы с пользователем уже существует изначально в виде сервиса с возможностью к нему обратиться с другого сервиса или расширить существующий. В этом случае, как раз трейты нашего любимого PHP, а также фасадный патерн для сервисов очень кстати.
С уважением всех читающих CoreJournal. Жду ваших ответов.
Но по поводу «Можно.» готов спорить прямо здесь. Я очень часто сталкиваюсь с проблемой того, что приложение на MVC/HMVC имеет серьезные проблемы с архитектурой.
Если принять Модель за интерфейс работы с данными, то остается вопрос куда деть интерфейсы для работы с другими интерфейсами (Внешние API к примеру).
Я придерживаюсь правила, что не должно быть функционала больше чем требуется в данный момент. Это делает более трудоемким процесс расширения возможностей общей системы, но никак не сложнее. (OverEngineering — BAD!) Но каждый фреймворк предоставляет нам готовый интерфейс взаимодействия пользователя с данными (в нашем случае WEB), и даже более, что не всегда используется.
Как итог, реализация на Symfony (как фреймворк, он меня вполне устраивает) способов авторизации через соц. сети выливается в ручную установку пакетов, настройку, написания контроллера, функционала менеджера модели пользователя… проблема исчезнет, если функционал для работы с пользователем уже существует изначально в виде сервиса с возможностью к нему обратиться с другого сервиса или расширить существующий. В этом случае, как раз трейты нашего любимого PHP, а также фасадный патерн для сервисов очень кстати.
С уважением всех читающих CoreJournal. Жду ваших ответов.
Почему никто не пользуется CMS при разработке высоконагруженных проектов? Все дело в том, что каждая из них спроектирована таким образом, чтобы всячески мешать разрабатывать какой-либо неспецифический функционал, не говоря о некоторых отдельных ситуациях.
Но как разработка неспецифического функционала связана с нагрузкой?
Если хорошенько подумать, то это — тот же самый MVC, только здесь роль модели выполняет наш Service, который, как мы видим, значительно отличается от устоявшихся стереотипичных ОРМ моделей.
По-хорошему, модель в MVC не должна быть моделью из ORM.
По-хорошему, модель в MVC не должна быть моделью из ORM.
По-хорошему, модель в MVC не должна ни от чего больше зависеть. А её персистентность и прочий ACID должны обеспечиваться контроллером. Будет он это делать с помощью ORM, ODM, а может хранить в файлах или объектной базе — исключительно его область ответственности, о которой модель с представлением знать не должны.
А её персистентность и прочий ACID должны обеспечиваться контроллером.
Уж если совсем по-хорошему — то контроллер про это тоже ничего не должен знать, а должен делегировать в бизнес-слой.
Какой слой в MVC вы называете бизнес-слоем?
Следующий за контроллером. MVC — это паттерн организации для представления, а бизнес (в норме) живет дальше.
Слои в MVC живут не дальше и не ближе.
Они живут независимо — гляньте картинку в википедии. Между слоями стрелочки в обе стороны. А у вас контроллер по неведомой причине посередине оказывается.
Представление обычно обращается к модели напрямую потому что только представление знает какие данные в каком виде ему нужны для рендеринга. Контроллер только дает команду — предьяви такой то контент. Например юзера васю пупкина.
А все потроха васи пупкина представление запрашивает у моели — нуджно только фамилию берет фамилию — надо фотку — тогда и фотку.
А еще модель может дернуть контроллер — у меня сменились данные (каким то стороним воздействием — что то отредактировали напрямую) — а ну-ка обнови представление актуальными данными…
Это если по уму — но поскольку MVC в вебе как я уже написал -полная чушь то тут конечно можно что угодно лепить.
Они живут независимо — гляньте картинку в википедии. Между слоями стрелочки в обе стороны. А у вас контроллер по неведомой причине посередине оказывается.
Представление обычно обращается к модели напрямую потому что только представление знает какие данные в каком виде ему нужны для рендеринга. Контроллер только дает команду — предьяви такой то контент. Например юзера васю пупкина.
А все потроха васи пупкина представление запрашивает у моели — нуджно только фамилию берет фамилию — надо фотку — тогда и фотку.
А еще модель может дернуть контроллер — у меня сменились данные (каким то стороним воздействием — что то отредактировали напрямую) — а ну-ка обнови представление актуальными данными…
Это если по уму — но поскольку MVC в вебе как я уже написал -полная чушь то тут конечно можно что угодно лепить.
А еще модель может дернуть контроллер — у меня сменились данные — а ну-ка обнови представление актуальными данными…
А как же паттерн Publisher-subscriber, который является неотъемлемой частью MVC, его почему забыли спросить, а сразу контроллер дергаете?
В MVC нет слоев, это паттерн для одного слоя (presentation). А я своей фразой имел в виду, что бизнес в сложном приложении находится в следующем слое (если не еще дальше).
А еще модель может дернуть контроллер — у меня сменились данные (каким то стороним воздействием — что то отредактировали напрямую) — а ну-ка обнови представление актуальными данными…
Если уж может, то не дернуть, а уведомить, и не контроллер, а представление. Работа контроллера: предоставить представлению модель для представления её состояния (по другому сложно выразить) и транслировать, если нужно, события представления в события модели, изменяющие, как правило, её состояние.
То, что в вебе называется MVC, на самом деле называется MVP и Presenter там как раз посередине, а что касается MVC — закопайте вы его уже и не насилуйте, этот паттерн был придуман для толстых клиентов (Java GUI, ...), оно для веба не применимо!
То, что в вебе называется MVC, на самом деле называется MVC Model 2. А MVP — это, скажем, asp.net WebForms.
В контексте PHP (да и Java послдених лет), это всё же ближе к MVP, или вы во view сервис передаёте? Подозреваю что это не так, и вы в контроллере собираете все необходимые данные по всем нужным сервисам и только потом отдаёте в новосозданную вьюху.
вы в контроллере собираете все необходимые данные по всем нужным сервисам и только потом отдаёте в новосозданную вьюху.
Вот это как раз прекрасно совпадает с описанием MVC Model 2.
А в MVP презентер (обычно) напрямую контролирует представление (например, как в WebForms).
Вот это как раз прекрасно совпадает с описанием MVC Model 2.
Там ключевым словом было «новосозданную», а вот MVC2 подразумевает, что она живёт отдельно от контроллера.
А в MVP презентер (обычно) напрямую контролирует представление (например, как в WebForms).
Что вы понимаете под «напрямую»? (Никогда просто не сталкивался с WebForms)
вот MVC2 подразумевает, что она живёт отдельно от контроллера.
Ээээ, где это Model 2 подразумевает, что модель живет отдельно от контроллера?
The servlet generates the dynamic content — in this example, the servlet uses JDBC to communicate with a database to obtain the content. The servlet then wraps the dynamic content into a bean. The JavaServer Pages file accesses the dynamic content from the bean
Что вы понимаете под «напрямую»? (Никогда просто не сталкивался с WebForms)
Веб-формы здесь ни при чем, это в любом MVP так. Под «напрямую» я понимаю то, что не значение выставляется в модели, а потом представление интерпретирует это значение, а презентер напрямую говорит представлению «сделай поле красным».
Ээээ, где это Model 2 подразумевает, что модель живет отдельно от контроллера?
В диаграмме классов
Веб-формы здесь ни при чем, это в любом MVP так. Под «напрямую» я понимаю то, что не значение выставляется в модели, а потом представление интерпретирует это значение, а презентер напрямую говорит представлению «сделай поле красным».
Спасибо, теперь я знаю чуточку больше :)
Вот вам картинка с отношением компонентов в Model 2. Там специально написано, что контроллер создает модель.
Даже с учётом простой возможности пуша событий (в данном контексте событий об изменении модели) с сервера на клиент через веб-сокеты? Давно можно считать, что View в вебе, это не шаблон на сервере, не ответ сервера клиенту, а вся веб-инфраструктура от веб-сервера до браузера пользователя, а HTTP с HTML лишь транспорт для взаимодействия View с остальнім приложением.
Давно можно считать, что View в вебе, это не шаблон на сервере, не ответ сервера клиенту, а вся веб-инфраструктура от веб-сервера до браузера пользователя, а HTTP с HTML лишь транспорт для взаимодействия View с остальнім приложением.
Это делает паттерн неопределенно размазанным.
А если убрать клиент извиду то все становится чуть проще, нет? Скажем… HTTP ответ — представление данных. HTTP запрос (или таск пришедший нам из MQ) — входящие данные, которые контроллер (из терминологии GRASP) обрабатывает (не сам, просит модель). А что там на клиенте — плевать.
Во всяком случае я начинаю нервничать когда фронтэдщики воспринимают свое приложение в контексте клиент-серверной архитектуры только как view, вынося контроллеры и модель целиком и полностью на сервер (посмотрите любую из многих презентаций в духе flux vs mvc).
Может быть у меня просто специфика такая (мобильные приложения, SPA), что у меня все живет себе отдельно… но вот честно, как по мне воспринимать все это добро как единое целое не правильно.
Во всяком случае я начинаю нервничать когда фронтэдщики воспринимают свое приложение в контексте клиент-серверной архитектуры только как view, вынося контроллеры и модель целиком и полностью на сервер (посмотрите любую из многих презентаций в духе flux vs mvc).
Может быть у меня просто специфика такая (мобильные приложения, SPA), что у меня все живет себе отдельно… но вот честно, как по мне воспринимать все это добро как единое целое не правильно.
А если убрать клиент извиду то все становится чуть проще, нет?
Да.
А что там на клиенте — плевать.
Это для пассивных клиентов хорошо. Для активных все неоднозначно.
но вот честно, как по мне воспринимать все это добро как единое целое не правильно.
А и не надо его воспринимать как единое целое. Есть две совершенно разных (хоть и взаимодействующих) модели — есть что, что происходит на http-сервере (от прихода запроса до рендера ответа), а есть то, что происходит на клиенте. И их парадигмы могут быть вообще не связанными.
Ну почему-же. Как раз в духе классицизма. Тут вопрос только где поставить границу контроллера и модели, по сути считать ли веб- и сокет-серверы частью контроллера или частью распределенного представления.
Именно потому, что непонятно, где ставить границы, и, как следствие, как разделять ответственности, и как реализовывать.
Ну, если считать, что модель уведомляет представление непосредственно, то там, где заканчивается модель — начинается представление :) С другой стороны MVC Не оговаривает механизма сообщений и можно всё от модели до браузера считать этим механизмом.
А как вы определите, где закончилась модель? А что считать контроллером?
Не, слишком много неизвестных.
Не, слишком много неизвестных.
А как в традиционных толстых клиентах или вообще стэнд-элон определяют? Мой посыл в том, что уже давно на уровне архитектуры можно считать браузер с исполняемым им кодом не тупым клиентом, по сути графическим терминалом, а полноценным узлом распределенного (по звезде) гетерогенного (если не ноду на сервере юзать) приложения. Скрывая детали реализации (периодический или длинный поллинг, честный пуш через сокеты или флэш) того же наблюдателя за абстракциями, на уровне архитектуры нам без разницы (ну, почти) работает вью на сервере или на другом конце мира.
А как в традиционных толстых клиентах или вообще стэнд-элон определяют?
По паттерну.
Мой посыл в том, что уже давно на уровне архитектуры можно считать браузер с исполняемым им кодом не тупым клиентом, по сути графическим терминалом, а полноценным узлом распределенного (по звезде) гетерогенного (если не ноду на сервере юзать) приложения.
Специфика презентационного слоя (layer) в том, что он всегда живет в одном уровне (tier). Соответственно, шаблоны этого слоя должны быть заключены в рамках одного, как вы выражаетесь, «узла».
на уровне архитектуры нам без разницы (ну, почти) работает вью на сервере или на другом конце мира.
Первое правило распределенных приложений: не пишите распределенных приложений. Позиция «нам на уровне архитектуры все равно, где работает (что угодно)» давно показала себя ошибочной; локальные и удаленные взаимодействия принципиально отличаются по своей сути. Вы можете только сделать вид, что все ваши взамодействия — удаленные (и заплатить соответствующие накладные расходы).
И вы почему-то постоянно забываете, что есть пассивные клиенты, у которых нет ни поллинга, ни пуша, ни флеша — ничего, просто HTML и немножко JS для местной интерактивности. Они никак не ложатся в ту парадигму классического MVC, которую вы предлагаете использовать.
Не надо путать ситуацию «у меня SPA/активный клиент, я с сервера таскаю только данные» и «у меня (полу)пассивный клиент, я с сервера таскаю HTML». У них просто разные шаблоны решения.
По паттерну.
Что мешает также определять в моем случае?
Первое правило распределенных приложений: не пишите распределенных приложений. Позиция «нам на уровне архитектуры все равно, где работает (что угодно)» давно показала себя ошибочной
Я знал, что вы скажете что-то в этом роде. :) Тем не менее, если мы готовы платить, то концепция имеет право на жизнь.
И вы почему-то постоянно забываете, что есть пассивные клиенты, у которых нет ни поллинга, ни пуша, ни флеша — ничего, просто HTML и немножко JS для местной интерактивности. Они никак не ложатся в ту парадигму классического MVC, которую вы предлагаете использовать.
У каких клиентов с местным JS нет возможности периодически опрашивать сервер «а не ли у модели уведомлений для меня» — классический поллинг? Но вообще, да, забываю, последние годы если не я принимаю решение, какие клиенты будут поддерживаться, а какие нет (или даже какие клиенты будут у пользователей), то, как минимум, точно знаю вплоть до номера билда и могут пробить решение обновить или даже откатиться до конкретного.
Не надо путать ситуацию «у меня SPA/активный клиент, я с сервера таскаю только данные» и «у меня (полу)пассивный клиент, я с сервера таскаю HTML». У них просто разные шаблоны решения.
А ситуацию «у меня активный клиент, который с сервера таскает фрагменты хтмл» куда отнести? Но вообще, да, на вырожденный случай (полу)пассивного клиента классический MVC ложится плохо.
Что мешает также определять в моем случае?
Ну так определите, я хочу на результат посмотреть.
Тем не менее, если мы готовы платить, то концепция имеет право на жизнь.
В этом случае вам придется разрабатывать любой клиент как SPA.
У каких клиентов с местным JS нет возможности периодически опрашивать сервер «а не ли у модели уведомлений для меня» — классический поллинг?
У любых, в которых накладные расходы на такой запрос (стоимость соединения, процессорное время, батарея) признаны избыточными для решения задачи.
А ситуацию «у меня активный клиент, который с сервера таскает фрагменты хтмл» куда отнести?
Зависит от того, какие действия и по какому алгоритму он предпринимает с этими фрагментами. Но вообще, скорее всего, вы получите два презентационных слоя, каждый со своим паттерном внутри.
Но вообще, да, на вырожденный случай (полу)пассивного клиента классический MVC ложится плохо.
Вот только это именно тот случай, который породил «серверное MVC» как мы его знаем — т.е., Model 2.
MVC Не оговаривает механизма сообщений
Она оговаривает что связь между view и model должна происходит за счет обзервабл отношений (ну то есть вью вешает подписчиков изменений модели). И это все имеет смысл только если у нас view живет дольше запроса.
Так в SPA и близких к ним приложениях view и живёт дольше запроса. А с применением server push (пускай даже физически реализованных поллингом на голом http) любая вкладка может подписаться на честное обновление. Большое ли значение имеет, что обзервабл отношения реализуются через http, а не внутрипроцессными вызовами?
у меня на SPA отношения реализуются между view (DOM) и моделью (сервис, просто какой-то объект в контексте JS приложения) за счет обзервабл связи (дата биндинг). Сервер, пуши там или чего еще выходит за рамки модели как средства обработки данных или являются деталью реализации, это просто поставщик данных.
То есть если мы в контексте SPA выкидываем сервер из уравнения под названием «что есть что в MVC», то все становится предельно просто и понятно. Сервер это тупо хранилище, мы можем заменить сервер на локал сторадж или sqlite или еще чего. От этого суть не поменяется вообще.
MVC это чисто схема организации UI приложения. У клиента это свой UI Layer, у сервера свой (HTTP API в контекте SPA, и пользователь будет — наш програмный клиент).
В противном случае, если мы рассматриваем сервер как «контроллер и модель», то тогда мы можем смело сказать что наше приложение это только контроллер а модель это база данных.
То есть если мы в контексте SPA выкидываем сервер из уравнения под названием «что есть что в MVC», то все становится предельно просто и понятно. Сервер это тупо хранилище, мы можем заменить сервер на локал сторадж или sqlite или еще чего. От этого суть не поменяется вообще.
MVC это чисто схема организации UI приложения. У клиента это свой UI Layer, у сервера свой (HTTP API в контекте SPA, и пользователь будет — наш програмный клиент).
В противном случае, если мы рассматриваем сервер как «контроллер и модель», то тогда мы можем смело сказать что наше приложение это только контроллер а модель это база данных.
Сервер тупо хранилище — только если на нем нет бизнес-логики, только если он выполняет чистые CRUD запросы, только запросы явно изменяющие состояние объектов в хранилище.
Модель в MVC — не просто поставщик данных в общем случае, это реализация бизнес-логики. Вью отображает какой-то срез состояния модели (обновления его, подписавшись на её события) и средства пользовательского интерфейса (поля формы, кнопки, ссылки), которые должны изменять состояние модели, но как его изменять вью не должно знать, оно лишь формирует сообщение котроллеру «пользователь заполнил эти элменты это формы вот так и нажал кнопку „отправить“, а контроллер транслирует это сообщение в сообщении модели в терминах бизнес-логики, например, „сделать перевод от клиента такого-то на такие-то реквизиты“. При этом его вообще не должно волновать как модель обрабатывает это сообщение. Если она изменит свое состояние в результате обработки (например, остаток средств у клиента), то она сама сообщит вьюхе об этом изменении.
А роль конкретного объекта в триаде MVC определяется не тем, где он физически (на компе клиента или в цоде) или логически (в процессе браузера, апп-сервера или СУБД) работает, а его ролью в приложении. И модель, и контроллер (включая взаимодействие с хранилищем), и представление могут быть размазаны по нескольким физическим узлам и логическим процессам, но при красивой архитектуре это размазывание прячется за абстракциями типа прокси и фасадов.
Если у вас сервер — это тупо хранилище, если всю бизнес-логику можно разместить на клиенте, то вам в чём-то повезло. Равно как и если всю бизнес-логику можно разместить на сервере. Но в последнее время из требований заказчиков всё чаще вытекает, что все компоненты триады должны быть размазаны и по клиенту, и по апп-серверу. Хорошо если базе данных можно отвести роль тупого хранилища, а не писать хранимки и триггеры.
Модель в MVC — не просто поставщик данных в общем случае, это реализация бизнес-логики. Вью отображает какой-то срез состояния модели (обновления его, подписавшись на её события) и средства пользовательского интерфейса (поля формы, кнопки, ссылки), которые должны изменять состояние модели, но как его изменять вью не должно знать, оно лишь формирует сообщение котроллеру «пользователь заполнил эти элменты это формы вот так и нажал кнопку „отправить“, а контроллер транслирует это сообщение в сообщении модели в терминах бизнес-логики, например, „сделать перевод от клиента такого-то на такие-то реквизиты“. При этом его вообще не должно волновать как модель обрабатывает это сообщение. Если она изменит свое состояние в результате обработки (например, остаток средств у клиента), то она сама сообщит вьюхе об этом изменении.
А роль конкретного объекта в триаде MVC определяется не тем, где он физически (на компе клиента или в цоде) или логически (в процессе браузера, апп-сервера или СУБД) работает, а его ролью в приложении. И модель, и контроллер (включая взаимодействие с хранилищем), и представление могут быть размазаны по нескольким физическим узлам и логическим процессам, но при красивой архитектуре это размазывание прячется за абстракциями типа прокси и фасадов.
Если у вас сервер — это тупо хранилище, если всю бизнес-логику можно разместить на клиенте, то вам в чём-то повезло. Равно как и если всю бизнес-логику можно разместить на сервере. Но в последнее время из требований заказчиков всё чаще вытекает, что все компоненты триады должны быть размазаны и по клиенту, и по апп-серверу. Хорошо если базе данных можно отвести роль тупого хранилища, а не писать хранимки и триггеры.
Сервер тупо хранилище — только если на нем нет бизнес-логики
На клиенте у меня за бизнес логику отвечает именно «модель» как какой-то объект в системе на клиенте. Там содержится бизнес логика и доступ к репозиторию с данными (ему ж надо откуда-то что-то брать что бы оперировать чем-то в рамках бизнес логики). А сервер выступает тупо как хранилище. То есть у сервера есть своя бизнес логика и клиент о ней особо не знает, он знает только то что относится к нему. Например у нас может быть мегасложная логика по разграничению прав, которая требует апрува от 10-ти пользователей и все такое. Клиенту важно только «есть у меня доступ или нет?».
То есть у меня часть бизнес логики вынесена на клиент, но это именно та логика которая относится конкретно к одному клиенту. Обычно на клиенте у нас весьма простая бизнес логика, что-то вроде «пользователь должен иметь пароль и логин».
А сервер уже умеет обрабатывать бизнес логику в больших масштабах (например он может разграничивать права, проверять подпадаем ли мы под ограничения в рамках этой бизнес логики и т.д.).
Опять же повторюсь, прямая аналогия — констрейты в базе данных. Она как бы не содержит «бизнес логики» но почему-то не дает вам удалить просто так записи на которые завязаны другие записи. Или не дает вам записать null в базу.
С точки зрения клиента для нашего приложения — сервер это тупо умное хранилище. С точки зрения сервера мы ничего не знаем о клиенте и чем он там занимается.
Для меня MVC (в норме) — это общий паттерн приложения:
— модель — содержит текущее состояние бизнес-процессов, изменяет это состояние при явном сообщении ей о каком-то событии
— представление — отображает в каком-то контексте модель, предоставляет средство генерации части событий
— контроллер — с одной стороны, предоставляет представлению нужный контекст модели, а, с другой, передаёт события, сгенерированные средствами представления, модели.
— модель — содержит текущее состояние бизнес-процессов, изменяет это состояние при явном сообщении ей о каком-то событии
— представление — отображает в каком-то контексте модель, предоставляет средство генерации части событий
— контроллер — с одной стороны, предоставляет представлению нужный контекст модели, а, с другой, передаёт события, сгенерированные средствами представления, модели.
Это сильное упрощение. Все ваше приложение сейчас — один слой (presentation). А представьте себе, что у вас одно и то же бизнес-приложение представляет наружу отдельно веб-морду и отдельно — API для мобильных клиентов?
(ну и да, то, что вы описываете, ближе к классическому MVC, чем к Model 2, который используется в web — это специально?)
(ну и да, то, что вы описываете, ближе к классическому MVC, чем к Model 2, который используется в web — это специально?)
Зачем мне представлять? У меня одна модель используется и в пользовательских веб-мордах, и для предоставления веб-сервисов разнообразным не браузерным клиентам, и даже вообще не для HTTP-клиентов, а, например, для SMTP-клиентов.
Что до Model 2, то я плохо знаком с ней — это же что-то из мира Java?
Что до Model 2, то я плохо знаком с ней — это же что-то из мира Java?
У меня одна модель используется и в пользовательских веб-мордах, и для предоставления веб-сервисов разнообразным не браузерным клиентам, и даже вообще не для HTTP-клиентов, а, например, для SMTP-клиентов.
Вот совсем одна-одна? Ничем нигде не отличается?
Что до Model 2, то я плохо знаком с ней — это же что-то из мира Java?
Нет, это «что-то», на чем основана добрая часть (за все говорить не буду) современных серверных MVC в вебе.
По сути, да, одна. Физически разбита на слабо зависящие друг от друга части, в разных подсистемах могут использоваться немного различающиеся версии, но это лишь временной лаг, просто разные таги на коммиты одной ветки.
Вот серьезно, не встречал (или как-то не обращал внимания) термина «MVC Model 2» в документации систем, которые использую или поглядываю с интересом. Если что, это не Oracle и не MS. Сам термин слышал, но обычно в контексте Java.
Вот серьезно, не встречал (или как-то не обращал внимания) термина «MVC Model 2» в документации систем, которые использую или поглядываю с интересом. Если что, это не Oracle и не MS. Сам термин слышал, но обычно в контексте Java.
По сути, да, одна.
И откуда вы берете такие полезные для представления вещи как «пункты в выпадающем списке», которым нет места в сервисном обмене?
Вот серьезно, не встречал (или как-то не обращал внимания) термина «MVC Model 2»
Потому что он в норме не используется, все просто пишут MVC, не задумываясь о том, что значение термина изменилось.
andrzejonsoftware.blogspot.ru/2011/09/rails-is-not-mvc.html
(строго то же самое можно сказать про asp.net MVC)
И откуда вы берете такие полезные для представления вещи как «пункты в выпадающем списке», которым нет места в сервисном обмене?
Механизмы разные, но источник данных пунктов один — модель.
Потому что он в норме не используется, все просто пишут MVC, не задумываясь о том, что значение термина изменилось.
Значит большинство материалов я интерпретировал неверно.
andrzejonsoftware.blogspot.ru/2011/09/rails-is-not-mvc.html
В свое время немало размышлял об этом. В то время серверные уведомления вообще были экзотикой для большинства веб-приложений. Для себя решил так — представление не обязано реагировать на изменения модели. Оно подписывается на интересующие его события модели, а в случае классического веба в бизнес-требованиях требуется лишь (после того как бизнес узнаёт о стоимости реализации подписки на уведомления) отображение состояния модели на конкретный момент времени, на начало какой-то бизнес-транзакции, как правило с оптимистичной блокировкой или вообще без неё.
Механизмы разные, но источник данных пунктов один — модель.
Но они же нерелевантны для сервисного обмена, значит, ваша модель для него избыточна.
Значит большинство материалов я интерпретировал неверно.
К сожалению, это давно существующая путаница.
Для себя решил так — представление не обязано реагировать на изменения модели.
Если оно не будет реагировать, то у вас не будет, собственно, классического MVC, потому что в нем единственный способ прохождения информации из модели в представление — это уведомление.
А её персистентность и прочий ACID должны обеспечиваться контроллером.
а может все таки персистентный хранилищем — ну там я знаю… сервером Бд например.
По-хорошему, модель в MVC не должна быть моделью из ORM.
по хорошему, если исходить из идеи MVC другой модели и не бывает, потому как модель — это модель бизнес-данных, включающая, к слову, и бизнес-логику.
Стопицот файлов в папке model это не модели, если по уму, а DTO. Даже если класс по совместительству является бизнес сущностью — User к примеру.
И контроллер кстати должен быть один. Потому контроллером скорее является роутер в точке входа где нибудь в index.php, чем опять же стопицот файлов в папке Controllers.
по хорошему, если исходить из идеи MVC другой модели и не бывает, потому как модель — это модель бизнес-данных, включающая, к слову, и бизнес-логику.
Я не знаю, где вы взяли такую идею MVC. Дадите источник?
И контроллер кстати должен быть один.
Аналогично — почему?
класический MVC как он был придуман — задолго до веба. И именно так он всегда и реализовывался в приложениях. В пятой визуал студио даже шаблон проекта был такой. Меню — контроллер, модель — документ. А в окне где рендерится документ — соответственно представление.
Word — как пример.
Word — как пример.
класический MVC как он был придуман — задолго до веба.
Конкретную цитату дать можете?
(я уж не говорю, что с тех пор много что поменялось)
В пятой визуал студио даже шаблон проекта был такой. Меню — контроллер, модель — документ. А в окне где рендерится документ — соответственно представление. Word — как пример.
А зачем вы пытаетесь все парадигмы свести к документоориентированной?
В пятой визуал студио даже шаблон проекта был такой
Вам тогда уж лучше в сторону Smalltalk смотреть, раз уж речь об истоках MVC зашла.
да дело не в истоках а в том где MVC паттерн применялся естественым образом. Четким, однозначным и понятным как полагается паттернам. Иначе это не паттерны.
Четким, однозначным, и понятным? А вы вот возьметесь четко и однозначно сказать — в ворде MVC или MVP?
Да где угодно вы его можете применить, если у вас есть некая логика, которая манипулирует данными, которые необходимо представлять независимым от логики образом.
«где угодно» и «патерн» — взаимоисключающие понятия.
Вы можете применить паттерн фасад или компоновщик где угодно — лишь бы данные были?
Вы можете применить паттерн фасад или компоновщик где угодно — лишь бы данные были?
Основной точкой для применения MVC должно быть, что у нас есть чётко очерченный круг данных, который чётко изменяется в ответ на чёткие события и нам нужно как-то отображать эти данные.
Ну если не рассматривать данные как сферу в вакууме, то они всегда как либо представляются и изменяются в ответ на множество событий (допустимо и нулевое множество, тогда данные не изменятся).
В рамках нашего приложения, а не вакууме. Грубо говоря, MVC излишня, что для приложения логгера, что для анализаторов логов, что для калькулятора, которій логи генерирует. Вот нужно одно приложение, что считает параметры, пишет историю своих исчислений и как-то их показывает — совсем другое дело…
Я надеюсь, вы в курсе, что то, что в серверных веб-приложениях называется MVC — это, на самом деле MVC Model 2, а не «классический MVC», пришедший из смолтолка?
В пятой визуал студио даже шаблон проекта был такой.
Меня лет 16-18 назад на собеседовании завалили на том, что я провёл аналогию между известным мне тогда MFC в (MS)С++ и неизвестным MVC на вакансию PHP-разработчика. Спустя буквально месяц (при фулл-тайм другой работе и семье) я осознал, что провёл аналогию слишком поспешно.
по хорошему, если исходить из идеи MVC другой модели и не бывает, потому как модель — это модель бизнес-данных
Причём тут ORM? Я могу хранить состояние бизнес-процессов не в реляционной базе даннных, вообще не в базе данных, вообще только в оперативке и, даже, вообще не хранить. А могу хранить в реляционной базе данных, но не маппить её на объекты.
Стопицот файлов в папке model это не модели, если по уму, а DTO
Не судите, да не судимы будете. Как только появляется хоть один метод типа из полей «Фамилия», «Имя», «Отчество» собрать значение «Фамилия Имя Отчество» — это 100% не DTO.
И контроллер кстати должен быть один.
Фаулеру может расскажете? Навскидку у него минимум три ФУНКЦИОНАЛЬНЫХ ТИПА контроллеров.
В 79-ом году под моделью понималась просто какая-то структура данных или объект, содержащий маленький кусок логики. А модель предметной области вообще ничего о ORM знать не должна.
Потом правда в 90-х пришли джависты и сказали что модель это сервис + какой-то DAO.
Потом правда в 90-х пришли джависты и сказали что модель это сервис + какой-то DAO.
>Почему никто не пользуется CMS при разработке высоконагруженных проектов?
Что есть высоконагруженный проект для вас? Если 2кк уников в день на один сервер — то вполне себе используют.
Суть то не в высоконагруженности, а на сколько функционал подходит, на сколько все реально доработать и тд, на основе этого понимаешь что взять, CMS, фреймворк или что-то среднее.
>Суть сего такова, что любые операции с данными системы, вычисляемыми данными,
>данными других сервисов позиционируются как Сервис. Сервис по сути является обычным пакетом PHP
>с классами и собственным пространством имен.
Выше уже написали про symfony. В целом оно там так и есть, но на самом деле, на практике понимаешь, что это спорный подход. Рекомендую сначала поюзать symfony чтобы понять неприятные моменты.
> Множество раз я пытался писать, следуя патерну, но результат всегда доводил меня до безумия.
Не слушайте всяких, пишите так как нравится вам, главное пишите, пишите много, изучайте чужой код, когда не знаете как лучше сделать что-то конкретное. Про патерны надо просто знать, что они есть, в какой-то момент вы просто поймете что вы им и так следуете, потому что в большинстве случаев это оптимальный способ решить определенные кейсы.
На счет написания своей CMS — так пишите да, писать код это всегда лучше чем не писать код. К тому же так оно как-то получается, что Пхп программист это не полноценный Пхп программист, если не написал хотябы пару своих CMS и не был облит дерьмом за это)
Что есть высоконагруженный проект для вас? Если 2кк уников в день на один сервер — то вполне себе используют.
Суть то не в высоконагруженности, а на сколько функционал подходит, на сколько все реально доработать и тд, на основе этого понимаешь что взять, CMS, фреймворк или что-то среднее.
>Суть сего такова, что любые операции с данными системы, вычисляемыми данными,
>данными других сервисов позиционируются как Сервис. Сервис по сути является обычным пакетом PHP
>с классами и собственным пространством имен.
Выше уже написали про symfony. В целом оно там так и есть, но на самом деле, на практике понимаешь, что это спорный подход. Рекомендую сначала поюзать symfony чтобы понять неприятные моменты.
> Множество раз я пытался писать, следуя патерну, но результат всегда доводил меня до безумия.
Не слушайте всяких, пишите так как нравится вам, главное пишите, пишите много, изучайте чужой код, когда не знаете как лучше сделать что-то конкретное. Про патерны надо просто знать, что они есть, в какой-то момент вы просто поймете что вы им и так следуете, потому что в большинстве случаев это оптимальный способ решить определенные кейсы.
На счет написания своей CMS — так пишите да, писать код это всегда лучше чем не писать код. К тому же так оно как-то получается, что Пхп программист это не полноценный Пхп программист, если не написал хотябы пару своих CMS и не был облит дерьмом за это)
Доступ к базе данных будет иметь только Service / Сервис
То есть каждый сервис держит («в уме» или конфигах) свою часть схемы базы (в случае РСУБД), открывает свой коннект к базе данных и если ему нужны данные из «чужого» куска базы, то получает их не путём запроса БД, а путём обращения к API другого сервиса (инициализующего новое соединение, открывающий новую транзакцию, выполняющее новый запрос) и сам обеспечивает целостность в конечном счёте с помощью самостоятельного управления распределенной (по сути) бизнес-транзакцией, состоящей из нескольких транзакций СУБД?
Это не просто вопрос ресурсов — это вопрос конкуренции за ресурсы.
Люди уже давно приспособили популярные CMS к нагрузкам. На том же WP крутятся сайты, вполне себе выдерживающие нагрузки. Поэтому не страдайте ерундой и сделайте что-то более полезное, чем очередную уникальную ноунейм CMS, которая никому, тем более для хайлоада, не будет нужна.
Show me the code!
По мне так этих cms уже как грязи, можно найти любую под любые требования, на любом языке, фреймворке, с любой архитектурой.
Успешность cms обусловлена ее продвижением или сложившейся исторической популярностью или количеством готовых решений на все случаи жизни(плагинов). Вы вряд ли сделаете свой продукт успешным.
Конечно вы можете ее писать для себя, ну как хобби, тогда вопросов нет кроме одного, зачем об этом на хабре писать?
Успешность cms обусловлена ее продвижением или сложившейся исторической популярностью или количеством готовых решений на все случаи жизни(плагинов). Вы вряд ли сделаете свой продукт успешным.
Конечно вы можете ее писать для себя, ну как хобби, тогда вопросов нет кроме одного, зачем об этом на хабре писать?
оффтоп
А есть хорошие CMS на NodeJS + MongoDB?
Часто у меня складывается впечатление, что народ не разобравшись в одном решении, придумывает то же самое и называет его другим именем. Не нашел в словах автора ни слова о функционале CMS, больше напоминает очередной фреймворк. Так же не понял людей, которые называют тот же Symfony CMS, хотя это обычный фреймворк без CMS функциональности.
На собственном опыте убедился, что больше не хватает небольших, сцепляющихся между собой пакетов, нежели готовых решений с вкрученной админкой и новостной лентой. Для «стандартных» сайтов давно есть хорошие CMS, а для частных решений только монстры-фреймворки.
Сам взялся за написание библиотеки на PHP, только не для широкой общественности.
На собственном опыте убедился, что больше не хватает небольших, сцепляющихся между собой пакетов, нежели готовых решений с вкрученной админкой и новостной лентой. Для «стандартных» сайтов давно есть хорошие CMS, а для частных решений только монстры-фреймворки.
Сам взялся за написание библиотеки на PHP, только не для широкой общественности.
Почитал ветку про MVC у убедился, что народ часто не понимает архитектур, с которыми работает.
А какую трактовку MVC вы считаете за правильную?
Ту, которая позволяет разделить представление и данные так, чтобы они друг с другом не взаимодействовали на прямую.
Неудачная трактовка, имхо.
Представление по сути своей должно представлять данные клиенту, а значит должно их получить. Если напрямую, то это может быть MVC. Если не напрямую, то єто какой-нибудь MVVC
Представление по сути своей должно представлять данные клиенту, а значит должно их получить. Если напрямую, то это может быть MVC. Если не напрямую, то єто какой-нибудь MVVC
Я не заморачиваюсь в сортах, суть везде одна, а мелкие детали обычно решаются контекстно.
Взаимодействуют или нет — это не мелкая деталь. Наличие и характер взаимодействий между логическими сущностями приложения и определяют применимость того или иного паттерна вообще.
Ту, которая позволяет разделить представление и данные так, чтобы они друг с другом не взаимодействовали на прямую.
Это называется Separated Presentation. MVC — только один из вариантов реализации.
Множество раз я пытался писать, следуя патерну, но результат всегда доводил меня до безумия.
Ожидаемо. Паттерн MVC в вебе, как я уже писал тут в своей публикации — как на корове седло. HMVC и прочие изощрения только доказывают несостоятельность MVC паттерна (имеется ввиду паттерн в вебе а не вообще).
Нет ничего естественнее для веба чем компонентный подход. Хотя бы потому что пользователь видит интерфейс и взаимодействует с элементами интерфейса а не с контроллерами. Если человек нажал кнопку то должно отработать событие связанное с кнопкой а не абстрактный экшен.
Пользователи веба не ограничиваются людьми, как минимум.
там где нет людей там как минимум нет представления.
В таких случаях используется что то типа сервисно-ориентированной архитектуры. И шо там вообще делать MVC?
В таких случаях используется что то типа сервисно-ориентированной архитектуры. И шо там вообще делать MVC?
там где нет людей там как минимум нет представления.
Это, на самом деле, неправда. Разные агенты могут запрашивать разные представления данных — одному подай XML, другому — JSON, третьему — HAL, с четвертым вообще на SOAP поговори.
с таким же успехом представлением можно назвать пакет байтов, возвращаемых драйвером сервера БД.
Я понимаю при желании термины MVC можно прикрутить к чему угодно. Только в этом случае не очевидно где что. и шо это за паттерн в таком случае?
Я понимаю при желании термины MVC можно прикрутить к чему угодно. Только в этом случае не очевидно где что. и шо это за паттерн в таком случае?
Я, кстати, не предлагаю «прикручивать термины MVC», я просто констатирую факт — представления есть не только в человеческих взаимодействиях, и та же парадигма разделения ответственной неплохо ложится и на агентные взаимодействия.
Я просто не могу сходу придумать более подходящего паттерна для описания того, как работают вменяемые web api (кроме message-driven, конечно).
Я просто не могу сходу придумать более подходящего паттерна для описания того, как работают вменяемые web api (кроме message-driven, конечно).
уверен что есть паттерны, описывающие сервисные архитектуры. и это не MVC паттерн.
Если брать MVC паттерн как идею отделения мух от котлет то конешно туда много чего подходит.
А вот когда доходит до конкретной реализации в стиле а-ля Zend. начинаются танцы с бубном, как у ТС.
И не только — обратите внимание на форумы сколько там дискусий — что должно относится к модели, кто должен передавать данные представлению контроллер или контроллер высчивает представление а представление само вычитывает модель.
Странно для вещи претендующей на названия паттерна — ведь смысл паттернов именно четкое описание архитектуры.
Если брать MVC паттерн как идею отделения мух от котлет то конешно туда много чего подходит.
А вот когда доходит до конкретной реализации в стиле а-ля Zend. начинаются танцы с бубном, как у ТС.
И не только — обратите внимание на форумы сколько там дискусий — что должно относится к модели, кто должен передавать данные представлению контроллер или контроллер высчивает представление а представление само вычитывает модель.
Странно для вещи претендующей на названия паттерна — ведь смысл паттернов именно четкое описание архитектуры.
Странно для вещи претендующей на названия паттерна — ведь смысл паттернов именно четкое описание архитектуры
Вполне себе четкое описание: вид -input-> контроллер -update-> модель -notify-> вид
Странно для вещи претендующей на названия паттерна — ведь смысл паттернов именно четкое описание архитектуры.
Но при этом многие паттерны нечетки в своих границах.
И не только — обратите внимание на форумы сколько там дискусий — что должно относится к модели, кто должен передавать данные представлению контроллер или контроллер высчивает представление а представление само вычитывает модель.
Большинство таких дискуссий можно закончить, если обратиться к первоисточникам.
дык вот незадача — никто так и может дать ссылку на такие чудодейственные первоисточники. Потому и бесконечные дискусии..
… и это неприменимо к большей части современного серверного MVC.
Не надо называть html-шаблон представлением и тогда хорошо применимо :)
А что, по-вашему, надо называть представлением в современном MVC (например, в asp.net MVC), и откуда вы возьмете события, на которых построено взаимодействие?
HTML-шаблон — лишь основа для построения представления. Само представление формируется на стороне клиента, в частности в виде DOM. Грубо, представление — это открытая вкладка браузера. Она уведомляет контроллеры о пользовательских событиях типа кликов, она может изменять своё состояние на основе уведомлений от модели (различные реализации server push).
Она уведомляет контроллеры о пользовательских событиях типа кликов,
Не обязательно. В значимой части случаев она просто отдает управление контроллеру, прекращая свое существование полностью.
она может изменять своё состояние на основе уведомлений от модели (различные реализации server push).
В asp.net MVC не используется server push (и вообще не используются уведомления). (я не говорю, что их нельзя сделать, просто они не входят в стандартный шаблон реализации)
Общий пойнт в том, что с точки зрения сервера того, что происходит на клиенте, не существует. Есть входящий запрос, есть его обработка, есть возвращенный результат. И это существенно лучше описывается в Model2, нежели в «классическом» MVC.
Не обязательно. В значимой части случаев она просто отдает управление контроллеру, прекращая свое существование полностью.
Вкладка в браузере не прекращает своё существование обычно при переходе по ссылке :) Если рассматривать именно вкладку, именно браузер как представление, то в терминах MVC представление у обычного веб-приложения одно, оно уведомляет контроллер о желании пользователя получить или изменить тот или иной фрагмент модели, а контроллер сообщает представлению интересующее его состояние модели.
с таким же успехом представлением можно назвать пакет байтов, возвращаемых драйвером сервера БД.
Классический пример MVC. Есть модель (физическое состояние базы на уровне ФС), есть контроллер — обработчик SQL-запросов, есть, как минимум, одно представление, представляющее интересующее состояние БД в конкретном виде (как правило, далеко отличном от уровня хранения).
К хабру обращаетесь за HTML-представлением интересующего вас URL, скорее всего, не вы, а ваш браузер. В случае клиент-серверных приложений, на стороне сервера MVC означает выдача представления для клиента (программного), а не для человека. И одна из фишек MVC состоит в том, чтобы разным клиентам отдавать разные представления одних и тех же данных. Или даже одному клиенту в разных контекстах…
Если человек нажал кнопку то должно отработать событие связанное с кнопкой а не абстрактный экшен.
А почему вы считаете, что в MVC по нажатию на кнопку отрабатывает «абстрактный экшн»? На мой взгляд, наоборот — вполне конкретный, явно связанный с этой кнопкой.
экшен вообще ни с чем не связанный, он сам по себе. Даже если его можно прикрутить к кнопке. А вообще можно куда угодно прикрутить.
экшен вообще ни с чем не связанный, он сам по себе.
Обработчик события — он тоже ни с чем не связан, его на что угодно можно повесить.
Другое дело, что экшн (обычно) совпадает с переходом в сценарии использования, и это логично.
Обработчик события — он тоже ни с чем не связан, его на что угодно можно повесить.
Обработчик события — всегда обработчик КОНКРЕТНОГО события — например нажатия на эту кнопку. Даже если вы его поцепили еще и на линк.
Обработчик события — всегда обработчик КОНКРЕТНОГО события — например нажатия на эту кнопку. Даже если вы его поцепили еще и на линк.
Не-а. Обработчик события — это делегат, принимающий те или иные аргументы. Точно так же, как экшн — это метод, принимающий те или иные аргументы.
Вы привязываете делегат к событию в момент подписания. Вы привязываете экшн к кнопке в момент написания соответствующего кода в представлении.
он абстрактный по назначению. Не проектируется екшен для связи с кнопкой.
У вас еще нет дизайна и вы не знаете какая там кнопка — но у вас уже может быть екшен — для выполнения какой то операции.
У вас еще нет дизайна и вы не знаете какая там кнопка — но у вас уже может быть екшен — для выполнения какой то операции.
он абстрактный по назначению. Не проектируется екшен для связи с кнопкой.
Кем не проектируется?
У вас еще нет дизайна и вы не знаете какая там кнопка — но у вас уже может быть екшен — для выполнения какой то операции.
А это зависит от того, как я иду. Если я иду от сценария использования, то у меня действия будут совпадать с шагами, а интерфейс я повешу потом. А если я иду от интерфейса, то у меня всем actionable items на интерфейсе будут соответствовать какие-то действия в контроллере (не обязательно один к одному).
Вы забываете про «наибольший общий делитель» — для классического HTML-приложения это два метода HTTP — GET и POST по отношению к конкретной сущности или коллекции сущностей. Всё. Никакие другие взаимодействия HTML over HTTP передавать не способен семантически, только получение сущности или коллекции, изменение сущности ( и то, под вопросом) и добавление сущности в коллекцию. Для сервера не существует события «человек нажал кнопку», для него существует событие «браузер отправил запрос на получение данных и(или) их изменение»
контролеров и экшенов для HTTP тоже не существует. Это архитектура поверх HTTP. .NET WebForms — класический пример с событиями.
Собственно — это пример компонентного подхода, гораздо более естественного для веба (для разработчиков веба) чем MVC.
Собственно — это пример компонентного подхода, гораздо более естественного для веба (для разработчиков веба) чем MVC.
Собственно — это пример компонентного подхода, гораздо более естественного для веба (для разработчиков веба) чем MVC.
Вы по себе судите обо всех разработчиках веба?
По HTTP есть ресурсы и методы, описывающие действия с ресурсами. Контроллеры и экшены обрабатывают эти методы и возвращаю результат, они не поверх HTTP, они реализуют HTTP. .NET WebForms — классическая попытка использовать HTTP лишь как транспорт, спрятанный от разработчика приложения за абстракциями, превращающими веб-приложение в приложение с толстым клиентом, а то и локальное.
В чём тут естественность для веб-разработчика, я не понимаю. Популярность .NET WebForms по сравнению с тем же .NET ASP MVC показывает, что не я один.
В чём тут естественность для веб-разработчика, я не понимаю. Популярность .NET WebForms по сравнению с тем же .NET ASP MVC показывает, что не я один.
Архитектура ASP.NET WebForms с событиями гораздо менее естественна для веба чем для толстых windows приложений. Контрольный вопрос вам:
Когда происходит событие в WebForms?
Когда происходит событие в WebForms?
MVC придумали в 79-ом году, за 36 лет он притерпел некоторые видоизменения. Канонический MVC сейчас кое-как можно найти в архитектуре GUI, и то не факт. У Мартина Фаулера есть неплохая статья на тему эволюции GUI архитектур.
Для бэкэнда же более больше смысла говорить об отделении бизнес логики от инфраструктуры и интерфейсов взаимодействия (http, cli, mq), но всем почему-то пристали к волшебным буквам MVC.
Для бэкэнда же более больше смысла говорить об отделении бизнес логики от инфраструктуры и интерфейсов взаимодействия (http, cli, mq), но всем почему-то пристали к волшебным буквам MVC.
Доступ к базе данных будет иметь только Service / Сервис
Да, читаем про шаблон “Репозиторий”
Сервис может содержать классы, трейты, Конфигурационные и кеш-файлы, базовые шаблоны
То есть свалка. Сервис должен быть объектом (плевать нам на классы, трейты и т.д. нас интересует только интерфейс) прежде всего, который реализует какие-то вещи. Читаем SOLID и чтим его. В идеале у нас есть сервисы-репозитории, которые знают что где хранится, у нас есть сервисы-декораторы, отвечающие за логирование и кеширование (читать шаблон «декоратор» и «адаптер»), и еще тысяча других сервисов. На каждый тип сервисов свой интерфейс, возможность выстраивать цепочку декораторов и тд. Тогда еще можно говорить о какой-то чистоте и гибкости.
Доступ к сервису будет осуществляться с помощью единого метода объекта из области контроллера
Читаем про dependency inversion, вооружаемся контейнером зависимостей (PHP-DI например) и вперед. А еще лучше — что бы наша CMS вообще ничего по умолчанию не знала о контроллерах. Что бы можно было быстро прикрутить API интерфейс или CLI интерфейс а контроллеры оставались настолько тонкими насколько это возможно. Вместо того что бы что-то делать в контроллерах пусть делегируют это какому-то сервису, реализующему конкретный юзкейс (сохранить страницу). Пусть поток данных и зависимостей всегда будет нацелен в одну сторону — снаружи внутрь. Внутренности приложения не должны зависеть от инфраструктуры.
Сервис обязательно имеет собственное пространство имен
очень мощное правило. Прям решает так много проблем. А главное, никто ж так не делает да. И ни слова что на каждый чих мы будем делать интерфейс главное.
тот же самый MVC
это уже обсудили выше, но… рекомендую к прочтению статейку под названием "эволюция MVC". Меня вообще забавляет как многие относятся к шаблонам проектирования. Когда только только вышла книжка банды четырех еще много холиваров было, полезная это штука или нет. Ведь это просто наблюдения, обобщение типичных решений которые уже были, никаких теоритических изысканий, только наблюдение. Только потом уже чувак по имени Крэйг Ларсон обобщил правила из которых формируются GoF-ские шаблоны (GRASP шаблоны). При этом я часто вижу как люди называют штуки ProductRepository вместо Catalog и т.д.
фасадный класс сервиса User
Вы знаете что такое «фасад»? Чувствуется влияние Laravel и их кастылей, которые слава богу можно уже не использовать в Laravel 5.
При этом я часто вижу как люди называют штуки ProductRepository вместо Catalog и т.д.
Видя название ProductRepository сразу понятна ответственность этого класса, можно даже предсказать сигнатуры методов. По названию же Catalog так не скажешь, особенно если предметную область не знаешь, даже слой не определить — может это представление какое, может прайс-лист, а может каталог диска.
Одно из назначений паттернов — облегчение коммуникаций между разработчиками и понятное другим именование сущностей основной способ коммуникаций.
даже предсказать сигнатуры методов.
да ну? Ну будет там методы add и remove, и собственно все, все остальное — зависит от логики. В целом пример наверное так себе…
Предсказания не обязательно на 100% точные :)
В любом случае название класса Repository говорит о том, что этот класс, реализует паттерн Repository, является хранилищем объектов класса , что в интерфейсе Repository активно используется . На деле может оказаться что угодно, но ожидания именно такие.
В любом случае название класса Repository говорит о том, что этот класс, реализует паттерн Repository, является хранилищем объектов класса , что в интерфейсе Repository активно используется . На деле может оказаться что угодно, но ожидания именно такие.
Ну как бы никто не мешает запилить нэймспейс например. Это уже вопрос организации кода. Вы же для декораторов не пишите NotifierLoggerDecorator, а скорее всего будет просто NotifierLogger.
Ну, можно, конечно, сделать что-то вроде App\Entity\Product и App\Repository\Product, но это детали. Главное чтобы полное имя репозитория продуктов содержало и Product и Repository :) А вот App\Catalog мало о чём говорит. А App\Repository\Catalog в лучшем случае не даёт информации какого типа данные в нём хранятся, а в худшем вводит в заблуждение, что это хранилище различных каталогов :)
.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пишу CMS на PHP. Часть 1