давай сначала про контейнер

зачем он тебе?

или почему у тебя его нет

Нет потому, что «он не нужен». Я не один в проекте) а нужен он для того, чтобы не плодить синглтоны и «уметь» автоматически резолвить необходимые зависимости

> а нужен он для того, чтобы не плодить синглтоны то есть есть всего два пути - контейнер зависимостей и сингелтоны?)

> «уметь» автоматически резолвить необходимые зависимости магия?)

Нет потому, что «он не нужен». Я не один в проекте) а нужен он для того, чтобы не плодить синглтоны и «уметь» автоматически резолвить необходимые зависимости

ну, вас много. и? вы же разные модули разрабатываете. почему у вас общий контекст Приложения?)

А много это сколько?

Есть общее «ядро» проектов, написанное не мной)

есть модули. есть Приложение, использующее модули. Это разные понятия. Контейнер в принципе для приложения нужен. Но и каждый модуль может иметь свой контейнер (вроде даже psr-fig пилят интерфейсы под это дело)

Ядро содержит минимум функциональности

Ядро содержит минимум функциональности

смотри, у тебя есть модуль Blog. Есть модуль User. В контексте ядра ты пишешь адаптер, который связывает два модуля, реализуя необходимые интерфейсы модулей. Не вижу проблему в такой схеме

ну или не ядра, а приложения, которое использует модули и ядро

Ядро содержит минимум функциональности

например?

я просто не понимаю что есть "ядро"

и зачем оно нужно

Реализацию HTTP, отдаленно напоминающую Симфони, кеш, логгер. Абстракция БД

короч фреймворк

окей....

я просто не понимаю что есть "ядро"

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

А вот врывается автор))₽

окей....

и вырывается, т.к. на работу пора.

у тебя есть фреймворк

твое приложение - это отдельная штука.

отдельная штука, работающая на основе ядра

при помощи инверсии зависимости например (если уж мы про гексагональную архитектуру заговорили)

причем не надо путать инверсию зависимости и инъекцию оных

инъекция зависимости это способ реализации инверсии управления

что бы фреймворк дергал приложение а не приложение фреймворк

писать свои фреймворки... в целом глупо... есть куча готовых. И компонентов готовых

вот я там чуть выше видос выкладывал почти про это

@POPSuL лучше объяснит, почему он написал ядро.

"захотелось", обычно по этой причине

"потому что гладиолус"

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

надо устроить митинг и рассказать всем почему именно так)

Сейчас у нас несколько подпроектов, которые завязаны на ядро. То есть мы как бы один большой проект, но внутри него подсайты

надо устроить митинг и рассказать всем почему именно так)

расскажи) интересно)

Сейчас у нас несколько подпроектов, которые завязаны на ядро. То есть мы как бы один большой проект, но внутри него подсайты

то есть "подсайты" дергают "ядро"?

Да.

При этом ядро не через композер установлено, в просто include.

делаем инверсию управления, и у нас развязаны руки

В остальном MVC

При этом ядро не через композер установлено, в просто include.

а это особенность, и я бы даже сказал, требование :)

> В остальном MVC в моем понимании это значит "фигачим в контроллерах"

MVC на бэкэнде не бывает)

делаем инверсию управления, и у нас развязаны руки

А как? Объясни, пожалуйста.

есть MVC Model2 из джава мира 90-х но мы же не про него?

А как? Объясни, пожалуйста.

ну.... например... можешь мне обрисовать что запускается первым? Есть какая-то точка входа?

> В остальном MVC в моем понимании это значит "фигачим в контроллерах"

Вот я и хочу отойти от этого.

ну ок

давай

точка входа, начнем с нее

она должна быть и должна быть только одна

как оно у тебя сейчас сделано?

ну.... например... можешь мне обрисовать что запускается первым? Есть какая-то точка входа?

Условно говоря, index.php на подпроекте. Дёргает ядро на запуск роутинга и соответствующего контроллера.

окей

пока все вроде как обычно

теперь что делают контроллеры кроме как работа с HTTP запросами/ответами?

есть ли что-то, что мешает вынести код получения данных/обработки данных в отдельные классы?

которые ничего не будут знать о ядре или о контроллерах

В общем-то ничего не мешает.

окей)

ну тогда... в чем проблема?

если ничего не мешает - значит проблемы нет

ERROR: S client not available

если тебя это ядро не заставляют суппортить - то проблемы вдвойне нет.

если ты можешь отгородиться от ядра своими адаптерами - все хорошо.

вопрос еще в том, есть ли в этом смысл

Ну, просто хотелось бы, чтобы на уровне ядра были решены некоторые вещи, которые сейчас на проектах плодятся в разных реализациях.

Фреймворки развразащают © ?

Ну, просто хотелось бы, чтобы на уровне ядра были решены некоторые вещи, которые сейчас на проектах плодятся в разных реализациях.

можешь привести пример? и почему бы эти решения не вынести как отдельные библиотеки?

CSRF (уже запилено), валидация данных, да тот же, прости господи, контейнер.

Под контейнером я, прежде всего, подразумеваю резолвинг, например, в контроллерах.

Т.е. я не предлагаю его пихать как зависимость в конструкторы каких-то классов.

1. Впили composer и сделай подключение твоего ядра через него 2. Добавляй что хочешь

пока я вижу лень)

@fes0r Еще вопрос (весьма животрепещующий) относительно зависимостей в Composer. Как решается вопрос с поддержанием их в актуальном состоянии так, чтобы ничего на других проектах не сломалось? Satis?

@fes0r Еще вопрос (весьма животрепещующий) относительно зависимостей в Composer. Как решается вопрос с поддержанием их в актуальном состоянии так, чтобы ничего на других проектах не сломалось? Satis?

в смысле?

git?

использовать фиксированные версии

@fes0r там выше @POPSuL уже сказал, что подключение через composer невозможно.

Ядра в смысле.

@fes0r там выше @POPSuL уже сказал, что подключение через composer невозможно.

нет ничего невозможного

локально его можно прицепить как компосер-проект, добавляешь гит-реп и пишешь зависимость. но в проде - нельзя.

если мне предоставят хотя бы один пункт почему "низя" - тогда будет предметнй разговор

локально его можно прицепить как компосер-проект, добавляешь гит-реп и пишешь зависимость. но в проде - нельзя.

в проде от композера надо только автозагрузчик

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

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

обратная совместимость

ничего не должно ломаться

)

если лень проверять руками - тесты

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

ну то есть ты написал тест, и теперь тебе запрещено его менять

тогда клиенты твоего класса (код который его юзают) точно не сломаются

А зачем вообще общие зависимоти у независимых проектов, у которых общее только ядро? Или ядро это больше чем вы сказали и там ещё какие-то данные и бизнес логика лежит?

Каждому проекту по своему composer.json и composer.lock

Vladimir http, db, cache, session, logger — вот эти вещи в ядре.