Muhammad: ну самый очевидный - вынести дублирование в отдельный объект. Ну и далее композиция, декорация и т.д. Наследование нужно там где оно подразумевается по иерархии типов.
Кот Учёный: ничего не понял. on build как раз выполняет команду внутри контейнера при сборке образа оного. То есть при таком раскладе мы не завязываемся на хосте и все клево.
Алекс: что значит "код меняется"? На продакшене? Это как?
Вообще делать npm install в рантайме плохо потому что npm install может не взлететь и "стабильность" контейнера окажется под большим сомнением. Но если вы осознаете риски - то вперед.
deadmemoras: нууу отдельная страница... это вы уж как хотите, там как бы PHP может ее формировать но весь чатик то всеравно на JS будет сделан. Можете апишку именно для "достать список чатов" и т.д. на PHP сделать. Просто сама реалтайм коммуникацию лучше делать на node.js. Под это дело он хорошо заточен и под это дело есть готовые решения (как для клиента так и для сервера).
Ну и еще - если это просто внутренний чатик, то проще взять полностью готовый солюшен вроде quickblox или layer.com или любой другой похожий.
Иван Корюков: и нет, MVC это таки паттерн. Потому что он описывает весьма маленькую штуку. Это не совокупность паттернов (хотя для контроллера есть GRASP контроллер, но это подходит не для всех MV*)
Иван Корюков: Action Domain Responder - это попытка спроэцировать тот самый аутентичный MVC на бэкэнд. Весьма провальная затея. Как минимум потому что экшен все же знает о респондере, а в аутентичном MVC контроллер ничего не знает о view и только обрабатывает события от контролов (то есть то что контролы висят во вью он не знает и знать не хочет).
Есть mediating controller MVC, который большинство и используют. Еще его называют MVA. И различие между MVP/MVVM и т.д. только в том сколько может быть вьюх и как организуется управление оными. От канонического MVC 79-ого года отличается координально тем что вью пассивно.
Проблема с ADR в том, что это "а давайте я просто переименую штуки и притяну зауши активное view из MVC туда куда не надо". Сама идея разделения ответственности между action и responder прикольная, но палки в колеса ставит то что экшен знает о респондерах, и еще хуже то что экшен знает о http. То есть у нас выходит.... ровно та же проблема. Толстые контроллеры, просто теперь это толстые экшены. И в большинстве реализаций экшен - это ажно целый класс, и разработчики пихают туда все что угодно.
У меня была попытка реализации ADR с абстрагированием экшенов от HTTP на уровне фронт контроллера, но не взлетело. Код быстрее писаться не стал, точнее стало больше конфигов и "конвеншенов". Сейчас у меня оооочень тонкие контроллеры а "сервисы" обрабатывающие действия вообще ничего не знают о http. Выходит очень быстро и удобно. Только вот придется ради этого из symfony заменить контейнер зависимостей на какой-нибудь поинтереснее, на php-di например.
DTX: сущность это сущность. Модель - это модель вашей системы (или той ее части, которая соприкасается с отдельным контроллером). Причем в большинстве случаев (9/10) модель выходит настолько тонкой (ну банально туда нечего ложить, логики мало) что многие реально думают что там тупо работа с базой. Отсюда и недопонимание.
сущность - это сущность. Это отдельный термин который никакого отношения к MVC не имеет. Точно так же как MVC не имеет отношения к архитектуре приложения. Это "паттерн" для реализации UI. Под моделью в нем подразумевается все что угодно у чего есть UI.
Дмитрий: вы должны разобраться какую проблему решает MVC. Зачем его придумали. Какие есть альтернативы (а их очень много, MVC самая старая из вариантов и в оригинальном виде мало кто ее использует сегодня, хотя кейсы для нее есть).
В большинстве своем MVC можно воспринимать как модную аббривиатуру и не более того.
неверно. Если у вас нет БД, что вы будете делать в модели?) Допустим у нас абсолютно stateless система, калькулятор. У нас не будет модели?
Вообще когда у вас состоянием одного объекта заведует другой - это называется процедурное программирование. Стэйт и процедуры. Никакого разделения ответственности, просто логика размазанная повсюду.
Александр: сервис - это просто какой-то объект (класс если хотите) который что-то делает. В вашем случае - управляет метаданными. Dependency Injection это просто одна из техник управления зависимостями и инверсии контроля, которая позволяет не писать кучу бойлерплейт кода.
И да, этот же подход можно для переводов использовать, но тут уже есть больше вариантов и все зависит от задачи. Например на моем последнем проекте для переводов я использовал как раз таки Embeddable потому что это была важная часть проекта а не второстепенная штука.
Алексей Скобкин: ай эти все Translatable и прочая чушь только плохо делают...
