Все мы хорошо знаем существующие популярные движки на PHP. Также можно упомянуть практически никому неизвестные, которые разрабатываются любителями. Но всех их объединяет одно большое «НО» в плане идеи, что собственно меня всегда и беспокоило. Почему никто не пользуется CMS при разработке высоконагруженных проектов? Все дело в том, что каждая из них спроектирована таким образом, чтобы всячески мешать разрабатывать какой-либо неспецифический функционал, не говоря о некоторых отдельных ситуациях.
Идея эта у меня появилась так же давно, как я начал программировать. С тех пор много лет прошло, много опыта набрался, практики. В общем, есть с чем сравнивать. Почти идеальным примером для меня является Django на Python'е. Но для конечного пользователя требуется огромное время для шлифовки интерфейса, базовых функций и прочего. И я подумал: не лучше ли мне писать ядро системы и прочее, под чутким руководством публики, которая предоставит максимум конструктивной критики в пользу моих наработок?
Базовые шаблоны программирования
Наиболее распространенным шаблоном программирования, по моему опыту, на данный момент является MVC и его модификации. Множество раз я пытался писать, следуя патерну, но результат всегда доводил меня до безумия. Нельзя так просто взять и разделить все на Model-View-Controller. Конечно, я могу ошибаться, и собственно потому вы это читаете.
Возьмем за пример простую работу с API и синхронизацию с данными модели к примеру User. За движок, фреймворк (кому как удобно) — Symfony. Я уверен: опытные в этом деле люди уже поняли с чего все начнется и чем все закончится.
Мою альтернативу я не могу назвать идеалом, но мне она очень по душе. Суть сего такова, что любые операции с данными системы, вычисляемыми данными, данными других сервисов позиционируются как Сервис. Сервис по сути является обычным пакетом PHP с классами и собственным пространством имен. Но кто мешает нам положить туда файл конфигураций, базовые шаблоны части View или кешируемые данные? Ведь все эти вещи относятся именно к нему, и стоит ли нам засорять общую папку для шаблонов/конфигов?
- Доступ к базе данных будет иметь только Service / Сервис
- Сервис может содержать классы, трейты, Конфигурационные и кеш-файлы, базовые шаблоны
- Доступ к сервису будет осуществляться с помощью единого метода объекта из области контроллера
- Сервис обязательно имеет собственное пространство имен
Такое решение значительно упрощает модуляцию всей системы. Когда ваш контроллер вообще не имеет доступа к базе данных, потребуется редактировать, к примеру, трейты сервиса, чтобы получить необходимые данные. Но с другой стороны, это очень поможет организовывать правильно код и не мешать одно с другим.
Если хорошенько подумать, то это — тот же самый MVC, только здесь роль модели выполняет наш Service, который, как мы видим, значительно отличается от устоявшихся стереотипичных ОРМ моделей.
Как результат, фасадный класс сервиса User может в себя вмещать работу с его локальными данными, собственными файлами на сервере, работу с API и прочее. Унификация такой большой области разработки дает возможность очень качественно реализовывать конечный результат.
Очень хотел бы узнать ваше мнение.
Комментарии (141)
NorthDakota
21.10.2015 11:33+3Нельзя так просто взять и разделить все на Model-View-Controller
Можно.
А то что вы хотите сделать будет HMVC
zenn
21.10.2015 11:57Действительно можно, тот же yii2 вам в пример с аналогичными «пакетами» (здесь они называются «расширения») — www.yiiframework.com/doc-2.0/guide-structure-extensions.html. Аналогичные подходы есть и в kohana и laravel с пакетными «наборами» и возможностью динамической инициации в роутере.
Fesor
22.10.2015 19:51я не уверен как это реализовано в laravel, но в symfony это реализовано достаточно грамотно. Там каждый элемент может иметь свой контроллер и для вызова оных делаются подзапросы. Удобно, легко реализовать, логично. Никаких отдельных виджетови прочих апишек.
CoreJournal
22.10.2015 22:48Если интересно развести холивар на тему, был бы очень рад побеседовать в личке (чтобы не засорять) и выяснить в чем отличия моей идеи и вашего HMVC.
Но по поводу «Можно.» готов спорить прямо здесь. Я очень часто сталкиваюсь с проблемой того, что приложение на MVC/HMVC имеет серьезные проблемы с архитектурой.
Если принять Модель за интерфейс работы с данными, то остается вопрос куда деть интерфейсы для работы с другими интерфейсами (Внешние API к примеру).
Я придерживаюсь правила, что не должно быть функционала больше чем требуется в данный момент. Это делает более трудоемким процесс расширения возможностей общей системы, но никак не сложнее. (OverEngineering — BAD!) Но каждый фреймворк предоставляет нам готовый интерфейс взаимодействия пользователя с данными (в нашем случае WEB), и даже более, что не всегда используется.
Как итог, реализация на Symfony (как фреймворк, он меня вполне устраивает) способов авторизации через соц. сети выливается в ручную установку пакетов, настройку, написания контроллера, функционала менеджера модели пользователя… проблема исчезнет, если функционал для работы с пользователем уже существует изначально в виде сервиса с возможностью к нему обратиться с другого сервиса или расширить существующий. В этом случае, как раз трейты нашего любимого PHP, а также фасадный патерн для сервисов очень кстати.
С уважением всех читающих CoreJournal. Жду ваших ответов.
stychos
21.10.2015 11:36+1О, я пишу примерно такой же велосипед, правда вместо сервисов по-старинке называю это модулями. Тоже порой не очень нравятся навязываемые фреймворками стандарты, ну и своё — оно всегда ближе к сердцу. Но этот путь справедлив, если пишешь только для себя.
lair
21.10.2015 11:46+2Почему никто не пользуется CMS при разработке высоконагруженных проектов? Все дело в том, что каждая из них спроектирована таким образом, чтобы всячески мешать разрабатывать какой-либо неспецифический функционал, не говоря о некоторых отдельных ситуациях.
Но как разработка неспецифического функционала связана с нагрузкой?
Если хорошенько подумать, то это — тот же самый MVC, только здесь роль модели выполняет наш Service, который, как мы видим, значительно отличается от устоявшихся стереотипичных ОРМ моделей.
По-хорошему, модель в MVC не должна быть моделью из ORM.VolCh
21.10.2015 12:01По-хорошему, модель в MVC не должна быть моделью из ORM.
По-хорошему, модель в MVC не должна ни от чего больше зависеть. А её персистентность и прочий ACID должны обеспечиваться контроллером. Будет он это делать с помощью ORM, ODM, а может хранить в файлах или объектной базе — исключительно его область ответственности, о которой модель с представлением знать не должны.lair
21.10.2015 13:19+1А её персистентность и прочий ACID должны обеспечиваться контроллером.
Уж если совсем по-хорошему — то контроллер про это тоже ничего не должен знать, а должен делегировать в бизнес-слой.VolCh
22.10.2015 01:12Какой слой в MVC вы называете бизнес-слоем?
lair
22.10.2015 01:13Следующий за контроллером. MVC — это паттерн организации для представления, а бизнес (в норме) живет дальше.
caballero
22.10.2015 02:06Слои в MVC живут не дальше и не ближе.
Они живут независимо — гляньте картинку в википедии. Между слоями стрелочки в обе стороны. А у вас контроллер по неведомой причине посередине оказывается.
Представление обычно обращается к модели напрямую потому что только представление знает какие данные в каком виде ему нужны для рендеринга. Контроллер только дает команду — предьяви такой то контент. Например юзера васю пупкина.
А все потроха васи пупкина представление запрашивает у моели — нуджно только фамилию берет фамилию — надо фотку — тогда и фотку.
А еще модель может дернуть контроллер — у меня сменились данные (каким то стороним воздействием — что то отредактировали напрямую) — а ну-ка обнови представление актуальными данными…
Это если по уму — но поскольку MVC в вебе как я уже написал -полная чушь то тут конечно можно что угодно лепить.
Delphinum
22.10.2015 02:09А еще модель может дернуть контроллер — у меня сменились данные — а ну-ка обнови представление актуальными данными…
А как же паттерн Publisher-subscriber, который является неотъемлемой частью MVC, его почему забыли спросить, а сразу контроллер дергаете?
lair
22.10.2015 02:13В MVC нет слоев, это паттерн для одного слоя (presentation). А я своей фразой имел в виду, что бизнес в сложном приложении находится в следующем слое (если не еще дальше).
VolCh
22.10.2015 03:06А еще модель может дернуть контроллер — у меня сменились данные (каким то стороним воздействием — что то отредактировали напрямую) — а ну-ка обнови представление актуальными данными…
Если уж может, то не дернуть, а уведомить, и не контроллер, а представление. Работа контроллера: предоставить представлению модель для представления её состояния (по другому сложно выразить) и транслировать, если нужно, события представления в события модели, изменяющие, как правило, её состояние.
saksmt
26.10.2015 08:09То, что в вебе называется MVC, на самом деле называется MVP и Presenter там как раз посередине, а что касается MVC — закопайте вы его уже и не насилуйте, этот паттерн был придуман для толстых клиентов (Java GUI, ...), оно для веба не применимо!
lair
26.10.2015 09:34То, что в вебе называется MVC, на самом деле называется MVC Model 2. А MVP — это, скажем, asp.net WebForms.
saksmt
27.10.2015 08:36В контексте PHP (да и Java послдених лет), это всё же ближе к MVP, или вы во view сервис передаёте? Подозреваю что это не так, и вы в контроллере собираете все необходимые данные по всем нужным сервисам и только потом отдаёте в новосозданную вьюху.
lair
27.10.2015 11:24+1вы в контроллере собираете все необходимые данные по всем нужным сервисам и только потом отдаёте в новосозданную вьюху.
Вот это как раз прекрасно совпадает с описанием MVC Model 2.
А в MVP презентер (обычно) напрямую контролирует представление (например, как в WebForms).
VolCh
27.10.2015 14:23Даже с учётом простой возможности пуша событий (в данном контексте событий об изменении модели) с сервера на клиент через веб-сокеты? Давно можно считать, что View в вебе, это не шаблон на сервере, не ответ сервера клиенту, а вся веб-инфраструктура от веб-сервера до браузера пользователя, а HTTP с HTML лишь транспорт для взаимодействия View с остальнім приложением.
lair
27.10.2015 16:22+1Давно можно считать, что View в вебе, это не шаблон на сервере, не ответ сервера клиенту, а вся веб-инфраструктура от веб-сервера до браузера пользователя, а HTTP с HTML лишь транспорт для взаимодействия View с остальнім приложением.
Это делает паттерн неопределенно размазанным.Fesor
27.10.2015 16:42А если убрать клиент извиду то все становится чуть проще, нет? Скажем… HTTP ответ — представление данных. HTTP запрос (или таск пришедший нам из MQ) — входящие данные, которые контроллер (из терминологии GRASP) обрабатывает (не сам, просит модель). А что там на клиенте — плевать.
Во всяком случае я начинаю нервничать когда фронтэдщики воспринимают свое приложение в контексте клиент-серверной архитектуры только как view, вынося контроллеры и модель целиком и полностью на сервер (посмотрите любую из многих презентаций в духе flux vs mvc).
Может быть у меня просто специфика такая (мобильные приложения, SPA), что у меня все живет себе отдельно… но вот честно, как по мне воспринимать все это добро как единое целое не правильно.lair
27.10.2015 16:47А если убрать клиент извиду то все становится чуть проще, нет?
Да.
А что там на клиенте — плевать.
Это для пассивных клиентов хорошо. Для активных все неоднозначно.
но вот честно, как по мне воспринимать все это добро как единое целое не правильно.
А и не надо его воспринимать как единое целое. Есть две совершенно разных (хоть и взаимодействующих) модели — есть что, что происходит на http-сервере (от прихода запроса до рендера ответа), а есть то, что происходит на клиенте. И их парадигмы могут быть вообще не связанными.
VolCh
27.10.2015 18:47Ну почему-же. Как раз в духе классицизма. Тут вопрос только где поставить границу контроллера и модели, по сути считать ли веб- и сокет-серверы частью контроллера или частью распределенного представления.
lair
27.10.2015 18:48+1Именно потому, что непонятно, где ставить границы, и, как следствие, как разделять ответственности, и как реализовывать.
VolCh
22.10.2015 02:56Для меня MVC (в норме) — это общий паттерн приложения:
— модель — содержит текущее состояние бизнес-процессов, изменяет это состояние при явном сообщении ей о каком-то событии
— представление — отображает в каком-то контексте модель, предоставляет средство генерации части событий
— контроллер — с одной стороны, предоставляет представлению нужный контекст модели, а, с другой, передаёт события, сгенерированные средствами представления, модели.lair
22.10.2015 11:25Это сильное упрощение. Все ваше приложение сейчас — один слой (presentation). А представьте себе, что у вас одно и то же бизнес-приложение представляет наружу отдельно веб-морду и отдельно — API для мобильных клиентов?
(ну и да, то, что вы описываете, ближе к классическому MVC, чем к Model 2, который используется в web — это специально?)VolCh
22.10.2015 12:51Зачем мне представлять? У меня одна модель используется и в пользовательских веб-мордах, и для предоставления веб-сервисов разнообразным не браузерным клиентам, и даже вообще не для HTTP-клиентов, а, например, для SMTP-клиентов.
Что до Model 2, то я плохо знаком с ней — это же что-то из мира Java?lair
22.10.2015 12:53У меня одна модель используется и в пользовательских веб-мордах, и для предоставления веб-сервисов разнообразным не браузерным клиентам, и даже вообще не для HTTP-клиентов, а, например, для SMTP-клиентов.
Вот совсем одна-одна? Ничем нигде не отличается?
Что до Model 2, то я плохо знаком с ней — это же что-то из мира Java?
Нет, это «что-то», на чем основана добрая часть (за все говорить не буду) современных серверных MVC в вебе.VolCh
22.10.2015 13:10По сути, да, одна. Физически разбита на слабо зависящие друг от друга части, в разных подсистемах могут использоваться немного различающиеся версии, но это лишь временной лаг, просто разные таги на коммиты одной ветки.
Вот серьезно, не встречал (или как-то не обращал внимания) термина «MVC Model 2» в документации систем, которые использую или поглядываю с интересом. Если что, это не Oracle и не MS. Сам термин слышал, но обычно в контексте Java.lair
22.10.2015 13:14По сути, да, одна.
И откуда вы берете такие полезные для представления вещи как «пункты в выпадающем списке», которым нет места в сервисном обмене?
Вот серьезно, не встречал (или как-то не обращал внимания) термина «MVC Model 2»
Потому что он в норме не используется, все просто пишут MVC, не задумываясь о том, что значение термина изменилось.
andrzejonsoftware.blogspot.ru/2011/09/rails-is-not-mvc.html
(строго то же самое можно сказать про asp.net MVC)VolCh
22.10.2015 13:40И откуда вы берете такие полезные для представления вещи как «пункты в выпадающем списке», которым нет места в сервисном обмене?
Механизмы разные, но источник данных пунктов один — модель.
Потому что он в норме не используется, все просто пишут MVC, не задумываясь о том, что значение термина изменилось.
Значит большинство материалов я интерпретировал неверно.
andrzejonsoftware.blogspot.ru/2011/09/rails-is-not-mvc.html
В свое время немало размышлял об этом. В то время серверные уведомления вообще были экзотикой для большинства веб-приложений. Для себя решил так — представление не обязано реагировать на изменения модели. Оно подписывается на интересующие его события модели, а в случае классического веба в бизнес-требованиях требуется лишь (после того как бизнес узнаёт о стоимости реализации подписки на уведомления) отображение состояния модели на конкретный момент времени, на начало какой-то бизнес-транзакции, как правило с оптимистичной блокировкой или вообще без неё.lair
22.10.2015 13:42Механизмы разные, но источник данных пунктов один — модель.
Но они же нерелевантны для сервисного обмена, значит, ваша модель для него избыточна.
Значит большинство материалов я интерпретировал неверно.
К сожалению, это давно существующая путаница.
Для себя решил так — представление не обязано реагировать на изменения модели.
Если оно не будет реагировать, то у вас не будет, собственно, классического MVC, потому что в нем единственный способ прохождения информации из модели в представление — это уведомление.
caballero
22.10.2015 01:07А её персистентность и прочий ACID должны обеспечиваться контроллером.
а может все таки персистентный хранилищем — ну там я знаю… сервером Бд например.VolCh
22.10.2015 01:11В рамках MVC — это ответственность контроллера. Кому или чему он её делегирует — ни модель, ни вью не касается.
caballero
22.10.2015 01:13По-хорошему, модель в MVC не должна быть моделью из ORM.
по хорошему, если исходить из идеи MVC другой модели и не бывает, потому как модель — это модель бизнес-данных, включающая, к слову, и бизнес-логику.
Стопицот файлов в папке model это не модели, если по уму, а DTO. Даже если класс по совместительству является бизнес сущностью — User к примеру.
И контроллер кстати должен быть один. Потому контроллером скорее является роутер в точке входа где нибудь в index.php, чем опять же стопицот файлов в папке Controllers.
lair
22.10.2015 01:14по хорошему, если исходить из идеи MVC другой модели и не бывает, потому как модель — это модель бизнес-данных, включающая, к слову, и бизнес-логику.
Я не знаю, где вы взяли такую идею MVC. Дадите источник?
И контроллер кстати должен быть один.
Аналогично — почему?caballero
22.10.2015 01:23-1класический MVC как он был придуман — задолго до веба. И именно так он всегда и реализовывался в приложениях. В пятой визуал студио даже шаблон проекта был такой. Меню — контроллер, модель — документ. А в окне где рендерится документ — соответственно представление.
Word — как пример.lair
22.10.2015 01:28класический MVC как он был придуман — задолго до веба.
Конкретную цитату дать можете?
(я уж не говорю, что с тех пор много что поменялось)
В пятой визуал студио даже шаблон проекта был такой. Меню — контроллер, модель — документ. А в окне где рендерится документ — соответственно представление. Word — как пример.
А зачем вы пытаетесь все парадигмы свести к документоориентированной?
Delphinum
22.10.2015 01:38В пятой визуал студио даже шаблон проекта был такой
Вам тогда уж лучше в сторону Smalltalk смотреть, раз уж речь об истоках MVC зашла.caballero
22.10.2015 01:55-1да дело не в истоках а в том где MVC паттерн применялся естественым образом. Четким, однозначным и понятным как полагается паттернам. Иначе это не паттерны.
lair
22.10.2015 01:58+1Четким, однозначным, и понятным? А вы вот возьметесь четко и однозначно сказать — в ворде MVC или MVP?
caballero
22.10.2015 02:14MVP придумали позже. Когда увидели что MVC не всегда лепится куда попало.
это как в квантовой физике — когда ученые не могут пояснить поведение частицы — они придумывают новую. И этих мюонов, мезонов и прочих уже больше чем ученых-физиков.lair
22.10.2015 02:16Позже, чем что?
Еще раз: вы можете отличить одно от другого по формальным критериям в живом приложении?
Delphinum
22.10.2015 01:58Да где угодно вы его можете применить, если у вас есть некая логика, которая манипулирует данными, которые необходимо представлять независимым от логики образом.
VolCh
22.10.2015 03:40Основной точкой для применения MVC должно быть, что у нас есть чётко очерченный круг данных, который чётко изменяется в ответ на чёткие события и нам нужно как-то отображать эти данные.
Delphinum
22.10.2015 03:49Ну если не рассматривать данные как сферу в вакууме, то они всегда как либо представляются и изменяются в ответ на множество событий (допустимо и нулевое множество, тогда данные не изменятся).
VolCh
22.10.2015 03:55В рамках нашего приложения, а не вакууме. Грубо говоря, MVC излишня, что для приложения логгера, что для анализаторов логов, что для калькулятора, которій логи генерирует. Вот нужно одно приложение, что считает параметры, пишет историю своих исчислений и как-то их показывает — совсем другое дело…
Delphinum
22.10.2015 03:59Ну ООП тоже часто считают излишним, что вполне закономерно. «Золотой молоток» ведь не зря считают антипаттерном.
lair
22.10.2015 02:22Я надеюсь, вы в курсе, что то, что в серверных веб-приложениях называется MVC — это, на самом деле MVC Model 2, а не «классический MVC», пришедший из смолтолка?
VolCh
22.10.2015 03:31В пятой визуал студио даже шаблон проекта был такой.
Меня лет 16-18 назад на собеседовании завалили на том, что я провёл аналогию между известным мне тогда MFC в (MS)С++ и неизвестным MVC на вакансию PHP-разработчика. Спустя буквально месяц (при фулл-тайм другой работе и семье) я осознал, что провёл аналогию слишком поспешно.
VolCh
22.10.2015 03:20по хорошему, если исходить из идеи MVC другой модели и не бывает, потому как модель — это модель бизнес-данных
Причём тут ORM? Я могу хранить состояние бизнес-процессов не в реляционной базе даннных, вообще не в базе данных, вообще только в оперативке и, даже, вообще не хранить. А могу хранить в реляционной базе данных, но не маппить её на объекты.
Стопицот файлов в папке model это не модели, если по уму, а DTO
Не судите, да не судимы будете. Как только появляется хоть один метод типа из полей «Фамилия», «Имя», «Отчество» собрать значение «Фамилия Имя Отчество» — это 100% не DTO.
И контроллер кстати должен быть один.
Фаулеру может расскажете? Навскидку у него минимум три ФУНКЦИОНАЛЬНЫХ ТИПА контроллеров.
Fesor
22.10.2015 19:53В 79-ом году под моделью понималась просто какая-то структура данных или объект, содержащий маленький кусок логики. А модель предметной области вообще ничего о ORM знать не должна.
Потом правда в 90-х пришли джависты и сказали что модель это сервис + какой-то DAO.
jrip
21.10.2015 11:58+4>Почему никто не пользуется CMS при разработке высоконагруженных проектов?
Что есть высоконагруженный проект для вас? Если 2кк уников в день на один сервер — то вполне себе используют.
Суть то не в высоконагруженности, а на сколько функционал подходит, на сколько все реально доработать и тд, на основе этого понимаешь что взять, CMS, фреймворк или что-то среднее.
>Суть сего такова, что любые операции с данными системы, вычисляемыми данными,
>данными других сервисов позиционируются как Сервис. Сервис по сути является обычным пакетом PHP
>с классами и собственным пространством имен.
Выше уже написали про symfony. В целом оно там так и есть, но на самом деле, на практике понимаешь, что это спорный подход. Рекомендую сначала поюзать symfony чтобы понять неприятные моменты.
> Множество раз я пытался писать, следуя патерну, но результат всегда доводил меня до безумия.
Не слушайте всяких, пишите так как нравится вам, главное пишите, пишите много, изучайте чужой код, когда не знаете как лучше сделать что-то конкретное. Про патерны надо просто знать, что они есть, в какой-то момент вы просто поймете что вы им и так следуете, потому что в большинстве случаев это оптимальный способ решить определенные кейсы.
На счет написания своей CMS — так пишите да, писать код это всегда лучше чем не писать код. К тому же так оно как-то получается, что Пхп программист это не полноценный Пхп программист, если не написал хотябы пару своих CMS и не был облит дерьмом за это)
stychos
21.10.2015 12:09+2Благодарю за последний абзац, Вы вдохнули немного свежих сил в меня, а то совсем было забросил свой велосипед и приуныл =)
VolCh
21.10.2015 12:09Доступ к базе данных будет иметь только Service / Сервис
То есть каждый сервис держит («в уме» или конфигах) свою часть схемы базы (в случае РСУБД), открывает свой коннект к базе данных и если ему нужны данные из «чужого» куска базы, то получает их не путём запроса БД, а путём обращения к API другого сервиса (инициализующего новое соединение, открывающий новую транзакцию, выполняющее новый запрос) и сам обеспечивает целостность в конечном счёте с помощью самостоятельного управления распределенной (по сути) бизнес-транзакцией, состоящей из нескольких транзакций СУБД?stychos
21.10.2015 12:12Возможно, в будущем все так и будут делать — это же вопрос ресурсов, зато меньше связность систем.
VolCh
22.10.2015 00:51Это не просто вопрос ресурсов — это вопрос конкуренции за ресурсы.
stychos
22.10.2015 01:04-1Ну это сейчас конкуренция может составлять проблемы, в будущем из-за увеличения скоростей схд или их соединения с персистентной оперативкой это может стать проще. Конечно, не исключаю и того, что количество информации, а значит и требования ко всяким субд в этом самом будущем также будут быстрее-выше-сильнее, а значит проблема может и не исчезнуть. Это я так, рассуждаю =)
VolCh
22.10.2015 01:09+1Проблема конкуренции не решается скоростями: сколь бы не стремилось к нулю время обработки одной транзакции вероятность того, что за это время начнётся вторая, использующая те же ресурсы — не нулевая.
stychos
22.10.2015 01:16Знаете, я совсем не разбираюсь в базах данных, чтобы рассуждать об этом на высоком уровне — повторюсь, это я просто так рассуждаю. Мне кажется что, например, если субд работает на скоростях, при которых время обработки транзакции стремится к нулю, то можно просто поменять логику её (субд) действий, чтобы она выстраивала все транзакции в очередь, или же можно отказаться от row-level locking и лочить строку целиком, ведь скорости уже (теоретически) позволяют.
Но в принципе Вы меня убедили, что не всё так просто, спасибо.VolCh
22.10.2015 03:48Собственно современные доминирующие реляционные базы данных и работают по принципу «все в очередь», если клиент объявляет транзакцию — как раз путём блокировки. Есть различные варианты организации очереди, но уж точно они атомарны на уровне UPDATE одной строки.
kovalevsky
21.10.2015 12:46Люди уже давно приспособили популярные CMS к нагрузкам. На том же WP крутятся сайты, вполне себе выдерживающие нагрузки. Поэтому не страдайте ерундой и сделайте что-то более полезное, чем очередную уникальную ноунейм CMS, которая никому, тем более для хайлоада, не будет нужна.
rsi
21.10.2015 14:38+5По мне так этих cms уже как грязи, можно найти любую под любые требования, на любом языке, фреймворке, с любой архитектурой.
Успешность cms обусловлена ее продвижением или сложившейся исторической популярностью или количеством готовых решений на все случаи жизни(плагинов). Вы вряд ли сделаете свой продукт успешным.
Конечно вы можете ее писать для себя, ну как хобби, тогда вопросов нет кроме одного, зачем об этом на хабре писать?Fesor
22.10.2015 19:57По мне так этих cms уже как грязи, можно найти любую под любые требования, на любом языке, фреймворке, с любой архитектурой.
Нормальных и юзабельных среди них не так много… к сожалению.
zBit
21.10.2015 17:27оффтопА есть хорошие CMS на NodeJS + MongoDB?
ainu
22.10.2015 17:28+1Есть, нашёл две, обе нехорошие (в плане UI и возможностей админа). Но быстрые. Пока ждём дальше. Вероятно, не дождёмся — кейсы «реалтайм обновление» и «чтобы картиночка обрезалась» не пересекаются.
Delphinum
21.10.2015 22:25+1Часто у меня складывается впечатление, что народ не разобравшись в одном решении, придумывает то же самое и называет его другим именем. Не нашел в словах автора ни слова о функционале CMS, больше напоминает очередной фреймворк. Так же не понял людей, которые называют тот же Symfony CMS, хотя это обычный фреймворк без CMS функциональности.
На собственном опыте убедился, что больше не хватает небольших, сцепляющихся между собой пакетов, нежели готовых решений с вкрученной админкой и новостной лентой. Для «стандартных» сайтов давно есть хорошие CMS, а для частных решений только монстры-фреймворки.
Сам взялся за написание библиотеки на PHP, только не для широкой общественности.Delphinum
22.10.2015 03:16Почитал ветку про MVC у убедился, что народ часто не понимает архитектур, с которыми работает.
VolCh
22.10.2015 03:49А какую трактовку MVC вы считаете за правильную?
Delphinum
22.10.2015 03:51+1Ту, которая позволяет разделить представление и данные так, чтобы они друг с другом не взаимодействовали на прямую.
VolCh
22.10.2015 03:58Неудачная трактовка, имхо.
Представление по сути своей должно представлять данные клиенту, а значит должно их получить. Если напрямую, то это может быть MVC. Если не напрямую, то єто какой-нибудь MVVCDelphinum
22.10.2015 04:01Я не заморачиваюсь в сортах, суть везде одна, а мелкие детали обычно решаются контекстно.
VolCh
22.10.2015 04:12+1Взаимодействуют или нет — это не мелкая деталь. Наличие и характер взаимодействий между логическими сущностями приложения и определяют применимость того или иного паттерна вообще.
Delphinum
22.10.2015 04:17Верно, но если для конкретного приложения вы не можете применить MVP, но можете MVC, то зачем углубляться в вопрос неприменимости одного и применимости другого? )
caballero
22.10.2015 01:04Множество раз я пытался писать, следуя патерну, но результат всегда доводил меня до безумия.
Ожидаемо. Паттерн MVC в вебе, как я уже писал тут в своей публикации — как на корове седло. HMVC и прочие изощрения только доказывают несостоятельность MVC паттерна (имеется ввиду паттерн в вебе а не вообще).
Нет ничего естественнее для веба чем компонентный подход. Хотя бы потому что пользователь видит интерфейс и взаимодействует с элементами интерфейса а не с контроллерами. Если человек нажал кнопку то должно отработать событие связанное с кнопкой а не абстрактный экшен.
VolCh
22.10.2015 01:13Пользователи веба не ограничиваются людьми, как минимум.
caballero
22.10.2015 01:29там где нет людей там как минимум нет представления.
В таких случаях используется что то типа сервисно-ориентированной архитектуры. И шо там вообще делать MVC?
lair
22.10.2015 01:30+3там где нет людей там как минимум нет представления.
Это, на самом деле, неправда. Разные агенты могут запрашивать разные представления данных — одному подай XML, другому — JSON, третьему — HAL, с четвертым вообще на SOAP поговори.caballero
22.10.2015 01:40с таким же успехом представлением можно назвать пакет байтов, возвращаемых драйвером сервера БД.
Я понимаю при желании термины MVC можно прикрутить к чему угодно. Только в этом случае не очевидно где что. и шо это за паттерн в таком случае?
lair
22.10.2015 01:43+1Я, кстати, не предлагаю «прикручивать термины MVC», я просто констатирую факт — представления есть не только в человеческих взаимодействиях, и та же парадигма разделения ответственной неплохо ложится и на агентные взаимодействия.
Я просто не могу сходу придумать более подходящего паттерна для описания того, как работают вменяемые web api (кроме message-driven, конечно).caballero
22.10.2015 01:50уверен что есть паттерны, описывающие сервисные архитектуры. и это не MVC паттерн.
Если брать MVC паттерн как идею отделения мух от котлет то конешно туда много чего подходит.
А вот когда доходит до конкретной реализации в стиле а-ля Zend. начинаются танцы с бубном, как у ТС.
И не только — обратите внимание на форумы сколько там дискусий — что должно относится к модели, кто должен передавать данные представлению контроллер или контроллер высчивает представление а представление само вычитывает модель.
Странно для вещи претендующей на названия паттерна — ведь смысл паттернов именно четкое описание архитектуры.
Delphinum
22.10.2015 01:55Странно для вещи претендующей на названия паттерна — ведь смысл паттернов именно четкое описание архитектуры
Вполне себе четкое описание: вид -input-> контроллер -update-> модель -notify-> вид
lair
22.10.2015 01:57Странно для вещи претендующей на названия паттерна — ведь смысл паттернов именно четкое описание архитектуры.
Но при этом многие паттерны нечетки в своих границах.
VolCh
22.10.2015 04:21И не только — обратите внимание на форумы сколько там дискусий — что должно относится к модели, кто должен передавать данные представлению контроллер или контроллер высчивает представление а представление само вычитывает модель.
Большинство таких дискуссий можно закончить, если обратиться к первоисточникам.caballero
22.10.2015 09:48дык вот незадача — никто так и может дать ссылку на такие чудодейственные первоисточники. Потому и бесконечные дискусии..
VolCh
22.10.2015 10:59lair
22.10.2015 11:28… и это неприменимо к большей части современного серверного MVC.
VolCh
22.10.2015 12:54Не надо называть html-шаблон представлением и тогда хорошо применимо :)
lair
22.10.2015 13:04А что, по-вашему, надо называть представлением в современном MVC (например, в asp.net MVC), и откуда вы возьмете события, на которых построено взаимодействие?
VolCh
22.10.2015 13:18HTML-шаблон — лишь основа для построения представления. Само представление формируется на стороне клиента, в частности в виде DOM. Грубо, представление — это открытая вкладка браузера. Она уведомляет контроллеры о пользовательских событиях типа кликов, она может изменять своё состояние на основе уведомлений от модели (различные реализации server push).
lair
22.10.2015 13:24Она уведомляет контроллеры о пользовательских событиях типа кликов,
Не обязательно. В значимой части случаев она просто отдает управление контроллеру, прекращая свое существование полностью.
она может изменять своё состояние на основе уведомлений от модели (различные реализации server push).
В asp.net MVC не используется server push (и вообще не используются уведомления). (я не говорю, что их нельзя сделать, просто они не входят в стандартный шаблон реализации)
Общий пойнт в том, что с точки зрения сервера того, что происходит на клиенте, не существует. Есть входящий запрос, есть его обработка, есть возвращенный результат. И это существенно лучше описывается в Model2, нежели в «классическом» MVC.VolCh
22.10.2015 13:57Не обязательно. В значимой части случаев она просто отдает управление контроллеру, прекращая свое существование полностью.
Вкладка в браузере не прекращает своё существование обычно при переходе по ссылке :) Если рассматривать именно вкладку, именно браузер как представление, то в терминах MVC представление у обычного веб-приложения одно, оно уведомляет контроллер о желании пользователя получить или изменить тот или иной фрагмент модели, а контроллер сообщает представлению интересующее его состояние модели.lair
22.10.2015 14:04В этом случае, к сожалению, единственное, с чем взаимодействует это «представление» — это веб-сервер (можете, на ваш выбор, назвать его моделью или контроллером, но не и тем, и другим одновременно), что лишает смысла все рассуждение.
VolCh
22.10.2015 04:17-1с таким же успехом представлением можно назвать пакет байтов, возвращаемых драйвером сервера БД.
Классический пример MVC. Есть модель (физическое состояние базы на уровне ФС), есть контроллер — обработчик SQL-запросов, есть, как минимум, одно представление, представляющее интересующее состояние БД в конкретном виде (как правило, далеко отличном от уровня хранения).
VolCh
22.10.2015 04:08-1К хабру обращаетесь за HTML-представлением интересующего вас URL, скорее всего, не вы, а ваш браузер. В случае клиент-серверных приложений, на стороне сервера MVC означает выдача представления для клиента (программного), а не для человека. И одна из фишек MVC состоит в том, чтобы разным клиентам отдавать разные представления одних и тех же данных. Или даже одному клиенту в разных контекстах…
lair
22.10.2015 01:16Если человек нажал кнопку то должно отработать событие связанное с кнопкой а не абстрактный экшен.
А почему вы считаете, что в MVC по нажатию на кнопку отрабатывает «абстрактный экшн»? На мой взгляд, наоборот — вполне конкретный, явно связанный с этой кнопкой.caballero
22.10.2015 01:26экшен вообще ни с чем не связанный, он сам по себе. Даже если его можно прикрутить к кнопке. А вообще можно куда угодно прикрутить.
lair
22.10.2015 01:29экшен вообще ни с чем не связанный, он сам по себе.
Обработчик события — он тоже ни с чем не связан, его на что угодно можно повесить.
Другое дело, что экшн (обычно) совпадает с переходом в сценарии использования, и это логично.caballero
22.10.2015 01:35Обработчик события — он тоже ни с чем не связан, его на что угодно можно повесить.
Обработчик события — всегда обработчик КОНКРЕТНОГО события — например нажатия на эту кнопку. Даже если вы его поцепили еще и на линк.lair
22.10.2015 01:37Обработчик события — всегда обработчик КОНКРЕТНОГО события — например нажатия на эту кнопку. Даже если вы его поцепили еще и на линк.
Не-а. Обработчик события — это делегат, принимающий те или иные аргументы. Точно так же, как экшн — это метод, принимающий те или иные аргументы.
Вы привязываете делегат к событию в момент подписания. Вы привязываете экшн к кнопке в момент написания соответствующего кода в представлении.caballero
22.10.2015 01:43обработчик события — всегда связан с событием. Это не просто функция. И параметры ему не нужны, кроме разве что ссылку на сендера.
А экшен можно и строки адреса ввода вызвать — это просто URL.lair
22.10.2015 01:44обработчик события — всегда связан с событием.
Чем связан?
Это не просто функция
А что еще?
А экшен можно и строки адреса ввода вызвать — это просто URL.
Любое взаимодействие в веб-приложении можно сымитировать из браузера — это «просто HTTP-запрос». В том числе и события.
И что с того?
caballero
22.10.2015 01:33он абстрактный по назначению. Не проектируется екшен для связи с кнопкой.
У вас еще нет дизайна и вы не знаете какая там кнопка — но у вас уже может быть екшен — для выполнения какой то операции.lair
22.10.2015 01:35он абстрактный по назначению. Не проектируется екшен для связи с кнопкой.
Кем не проектируется?
У вас еще нет дизайна и вы не знаете какая там кнопка — но у вас уже может быть екшен — для выполнения какой то операции.
А это зависит от того, как я иду. Если я иду от сценария использования, то у меня действия будут совпадать с шагами, а интерфейс я повешу потом. А если я иду от интерфейса, то у меня всем actionable items на интерфейсе будут соответствовать какие-то действия в контроллере (не обязательно один к одному).
VolCh
22.10.2015 04:37Вы забываете про «наибольший общий делитель» — для классического HTML-приложения это два метода HTTP — GET и POST по отношению к конкретной сущности или коллекции сущностей. Всё. Никакие другие взаимодействия HTML over HTTP передавать не способен семантически, только получение сущности или коллекции, изменение сущности ( и то, под вопросом) и добавление сущности в коллекцию. Для сервера не существует события «человек нажал кнопку», для него существует событие «браузер отправил запрос на получение данных и(или) их изменение»
caballero
22.10.2015 09:47-2контролеров и экшенов для HTTP тоже не существует. Это архитектура поверх HTTP. .NET WebForms — класический пример с событиями.
Собственно — это пример компонентного подхода, гораздо более естественного для веба (для разработчиков веба) чем MVC.lair
22.10.2015 11:29+1Собственно — это пример компонентного подхода, гораздо более естественного для веба (для разработчиков веба) чем MVC.
Вы по себе судите обо всех разработчиках веба?
VolCh
22.10.2015 12:39По HTTP есть ресурсы и методы, описывающие действия с ресурсами. Контроллеры и экшены обрабатывают эти методы и возвращаю результат, они не поверх HTTP, они реализуют HTTP. .NET WebForms — классическая попытка использовать HTTP лишь как транспорт, спрятанный от разработчика приложения за абстракциями, превращающими веб-приложение в приложение с толстым клиентом, а то и локальное.
В чём тут естественность для веб-разработчика, я не понимаю. Популярность .NET WebForms по сравнению с тем же .NET ASP MVC показывает, что не я один.
mird
22.10.2015 15:22+1Архитектура ASP.NET WebForms с событиями гораздо менее естественна для веба чем для толстых windows приложений. Контрольный вопрос вам:
Когда происходит событие в WebForms?
Fesor
22.10.2015 20:01MVC придумали в 79-ом году, за 36 лет он притерпел некоторые видоизменения. Канонический MVC сейчас кое-как можно найти в архитектуре GUI, и то не факт. У Мартина Фаулера есть неплохая статья на тему эволюции GUI архитектур.
Для бэкэнда же более больше смысла говорить об отделении бизнес логики от инфраструктуры и интерфейсов взаимодействия (http, cli, mq), но всем почему-то пристали к волшебным буквам MVC.
Fesor
22.10.2015 23:34Доступ к базе данных будет иметь только Service / Сервис
Да, читаем про шаблон “Репозиторий”
Сервис может содержать классы, трейты, Конфигурационные и кеш-файлы, базовые шаблоны
То есть свалка. Сервис должен быть объектом (плевать нам на классы, трейты и т.д. нас интересует только интерфейс) прежде всего, который реализует какие-то вещи. Читаем SOLID и чтим его. В идеале у нас есть сервисы-репозитории, которые знают что где хранится, у нас есть сервисы-декораторы, отвечающие за логирование и кеширование (читать шаблон «декоратор» и «адаптер»), и еще тысяча других сервисов. На каждый тип сервисов свой интерфейс, возможность выстраивать цепочку декораторов и тд. Тогда еще можно говорить о какой-то чистоте и гибкости.
Доступ к сервису будет осуществляться с помощью единого метода объекта из области контроллера
Читаем про dependency inversion, вооружаемся контейнером зависимостей (PHP-DI например) и вперед. А еще лучше — что бы наша CMS вообще ничего по умолчанию не знала о контроллерах. Что бы можно было быстро прикрутить API интерфейс или CLI интерфейс а контроллеры оставались настолько тонкими насколько это возможно. Вместо того что бы что-то делать в контроллерах пусть делегируют это какому-то сервису, реализующему конкретный юзкейс (сохранить страницу). Пусть поток данных и зависимостей всегда будет нацелен в одну сторону — снаружи внутрь. Внутренности приложения не должны зависеть от инфраструктуры.
Сервис обязательно имеет собственное пространство имен
очень мощное правило. Прям решает так много проблем. А главное, никто ж так не делает да. И ни слова что на каждый чих мы будем делать интерфейс главное.
тот же самый MVC
это уже обсудили выше, но… рекомендую к прочтению статейку под названием "эволюция MVC". Меня вообще забавляет как многие относятся к шаблонам проектирования. Когда только только вышла книжка банды четырех еще много холиваров было, полезная это штука или нет. Ведь это просто наблюдения, обобщение типичных решений которые уже были, никаких теоритических изысканий, только наблюдение. Только потом уже чувак по имени Крэйг Ларсон обобщил правила из которых формируются GoF-ские шаблоны (GRASP шаблоны). При этом я часто вижу как люди называют штуки ProductRepository вместо Catalog и т.д.
фасадный класс сервиса User
Вы знаете что такое «фасад»? Чувствуется влияние Laravel и их кастылей, которые слава богу можно уже не использовать в Laravel 5.VolCh
23.10.2015 07:43При этом я часто вижу как люди называют штуки ProductRepository вместо Catalog и т.д.
Видя название ProductRepository сразу понятна ответственность этого класса, можно даже предсказать сигнатуры методов. По названию же Catalog так не скажешь, особенно если предметную область не знаешь, даже слой не определить — может это представление какое, может прайс-лист, а может каталог диска.
Одно из назначений паттернов — облегчение коммуникаций между разработчиками и понятное другим именование сущностей основной способ коммуникаций.Fesor
23.10.2015 09:29даже предсказать сигнатуры методов.
да ну? Ну будет там методы add и remove, и собственно все, все остальное — зависит от логики. В целом пример наверное так себе…VolCh
23.10.2015 11:46Предсказания не обязательно на 100% точные :)
В любом случае название класса Repository говорит о том, что этот класс, реализует паттерн Repository, является хранилищем объектов класса , что в интерфейсе Repository активно используется . На деле может оказаться что угодно, но ожидания именно такие.Fesor
23.10.2015 11:56Ну как бы никто не мешает запилить нэймспейс например. Это уже вопрос организации кода. Вы же для декораторов не пишите NotifierLoggerDecorator, а скорее всего будет просто NotifierLogger.
VolCh
23.10.2015 12:50Ну, можно, конечно, сделать что-то вроде App\Entity\Product и App\Repository\Product, но это детали. Главное чтобы полное имя репозитория продуктов содержало и Product и Repository :) А вот App\Catalog мало о чём говорит. А App\Repository\Catalog в лучшем случае не даёт информации какого типа данные в нём хранятся, а в худшем вводит в заблуждение, что это хранилище различных каталогов :)
maxru
Моё мнение — пора прекращать сочинять велосипеды.
http://cmf.symfony.com/
jrip
К такому мнению разные люди, использующие PHP, переодически приходят уже вот лет 15.
maxru
И не только PHP, суть не в этом.
jrip
Суть в том, что если есть люди у которых есть возможность и желание сделать что-то свое, пусть и велосипед, то не надо им высокомерно мешать, кто-то, пусть и не все, возможно сделают что-то более лучшее, symfony не является идеалом и конечной точкой развития.
maxru
Symfony не идеален, поэтому возьмём Symfony и на его базе переизобретём велосипед, ага.
Lachezis
Фреймворк или CMS это прежде всего инфраструктура и архитектура, а не набор формирующих компонент (симфони тут кстати очень хорош).
ainu
Люди, которые разрабатывают сайты-сервисы, CRM, ecommerce и т.п. придут к такому мнению, и они косо смотрят на людей, которым нужна нормальная админка (не сгенерируемая и не «готовый бандл»), т.к. для них это первично. Красивый код нужен, расширяемость и поддерживаемость нужна, нужен удобный роутер и класс генерации SQL. Для них админка на маркдауне — это нормально.
Люди, которые разрабатывают сайты-визитки, каталоги и блоги, не придут к такому мнению и косо смотрят на людей, которым нужен MVC, но которые считают позволительным дать админу (а это может быть секретарша фирмы по продаже железобетона) редактировать текст страницы в маркдауне и конфиг в json. Важна автообрезка фотографий и их загрузка, важен вузивиг.
Нельзя путать CMF/фреймворки и CMS — разные кейсы, разные люди. Одни считают что, любой сайт можно сделать на Yii/Symphony (а других они и не делают), другие считают, что важно писать мало кода и быстро стартовать проект, и чтобы перетаскиванием картинка вставлялась в новость, и этого не надо было программировать. Обе группы косо друг на друга смотрят и не понимают друг друга.
В конце концов, тот же новый lumen от Laravel — тоже велосипед в каком то роде.
Fesor
И что в этом плохого? Если речь идет о лэндингах, то это очень даже удобно. Я когда-то сильно в этом сомневался но после того как впилил управление контентом на markdown на нескольких проектах и наблюдал как с этим делом работают контент менеджеры — им нравилось. Работали с системами девочки не сильно шарящие во всяких там делах.
Конфиги в json это да, это плохо. Ну и я тоже не фанат автосгенерированных админок, гридов и тупых крудов которые делают большинство.
Нет, нынче фреймворки это не монолитный трешь а набор компонентов. Lumen это просто другой набор компонентов, чуть более легковестных. Например там заменили мощьный и гибкий (а так же медленный) symfony/routing на fastroute от ника. Вот и все отличия. Не велосипеды, просто пак библиотек.
К слову о библиотеках. Буквально сегодня искал возможность быстро организовать CMS функциональность для проекта. И это либо были CMS-ки расчитанные на использование оных как основы для проекта, либо недобиблиотеки с убогими админками. И вот это расстраивает. В то же время можно было бы сделать удобный компонент для управления контентом который не завязан на все эти убогие инфраструктуры хаков и плагинов, который можно расширять декорацией и композицией классов и т.д.
CoreJournal
Symfony от Sensiolabs я использовал в реальных проектах не один раз. Задача стоит не такая. Да и идея совсем не та. Symfony настоящий Framework on PHP. Но никак не готовая CMS. Я хочу написать «валидную» с точки зрения разработки и масштабируемости систему, которой сможет пользоваться даже дедушка.
Понимаете ли, взяв к примеру WordPress, DLE или прочие CMS, мы получим практически идеальную с точки зрения конечного пользователя (не отходящего за рамки возможностей) систему для администрирования блога или новостной ленты. Но также есть масса потребностей и спроса на хорошо поддерживаемую и понятную со всех сторон систему, которая предоставит удобный интерфейс как для пользователя так и для разработчика.
Работая в компании на протяжении последних нескольких лет, становится ясно чего хочет заказчик. Но увы, редко попадаются командные проекты чтобы начать писать что-то стоящее. И я не желаю тратить время на холивар о том, как много уже написано и «не пиши велосипеды». Все это уместно в конкретных ситуациях. Но если заказчик не из «нашего мира», и захочет магазин на WP, то и альтернатива для него в виде OpenCart к примеру, будет неуместна.
В данной ситуации, моя задача узнать какой максимально понятный програмный интерфейс для масштабируемости выбрать для своей CMS. Заметьте, что я ничего не пытаюсь вам навязать, продать или прорекламировать. Также вам не удастся отговорить меня воротить такими вещами и изобретать велосипеды. В каждом последующем посту, я буду выкладывать не однозначные задачи по решению конкретных архитектурных и программных вопросов.
З.Ы. Только за сотрудничество!)
Fesor
Все фреймворки это только инфраструктура приложения. CMS обычно — полноценное приложение. Попытки сделать универсальное приложение обречены на провал изначально.
Можно как и в случае фреймворков попытаться обобщить проблемы, разбить все на отдельные компоненты что бы собирать готовую систему из конструктора, но почему-то выходят монолитные и неповоротливые монстры. Причем все хотят сделать универсальную систему, а ее потом интегрировать боль.
А люди потом на этом заказывают интернет магазины и соц сети. И в этом проблема.
Оно всегда понятно, он хочет что бы продукт приносил бабло. Удобство использования со стороны контент менеджера снижает затраты, вот и все.
Где-то год назад я обдумывал как сделать нашим маркетологам простенькую CMS-ку затратив минимум усилий и с которой им будет удобно работать (не дергать программистов на каждый чих). В итоге, пройдя по граблям, если у меня будет такая задача в будущем я просто возьму любой генератор статический сайтов, настрою CI-ку на билд проекта, сделаю возможность собирать странички из блоков (yaml, markdown + A/B тестирование), напишу простенький web-интерфейс скрывающий работу с git и т.д. и это будет всеравно проще чем писать полноценную CMS с базами данных и т.д. В итоге же под задачи наших маркетологов готовые CMS-ки стали быстро замедлять работу.
ну у вас по сути еще нет продукта. А судя по описанию он так же скорее всего не подойдет под те задачи, которые попадаются мне.
Delphinum
Так вроде Unix-философия давным давно ответила на этот вопрос. Гляньте на реализацию модульности в zf2, на мой взгляд это один из хороших примеров.