Где-то в начале 2к годов, был на собеседовании по CPP,.. прошёл, но пообещали мало платить. Тогда помню, это так на меня повлияло, что даже основной стек поменял на веб. Сейчас смотрю, годы идут, а там похоже ничего не меняется.
Могу со стороны себя сказать, нет, программисты обычно так сконцентрированы на решении задач, что им нет никакого дела понимать проблемы продажников и пр. очень нужных сотрудников.
Кто вам сказал, что скрываются предусловия?!
Все фабрики генерируемых классов, различные мидлвэры прописываются в конфигах, а сервис локатор последовательно использует эти настройки при генерации объекта.
Если делать объекты через new, то это засоряет код, а если кода много, то становится максимально неудобно.
Также если вам потребовалась для обработки гора параметров в классе, то это уже невалидный код и так писать не надо. Логику обработок можно раскидать по тем же мидлверам/фабрикам. Действуя принципам SOLID 1 класс 1 задача, что по итогу будет класс оперирующий высокоуровневой логикой.
Параметры в конструкторе класса на этом фоне выглядят мягко-говоря лишними, только добавляющими сложности при создании объекта.
Если нужны параметры, используйте сеттеры и валидаторы.
Видимо не понимаю вас, объект создаётся классическим способом, через конструктор.
В конструкторе прописаны зависимости, как параметры. Когда создаётся объект, подразумевается, что параметры должны быть заданы.
Не помню точно, как в Symfony реализация, но если взять для примера Magento 2 (там тоже передача зависимостей через конструктор), то там происходит генерация параметров конструктора и подстановка в вызов. И даже если параметры потом ансетить, это всё равно лишние операции, лишняя логика.
Как нибудь будет время посмотрю подробнее этот процесс, но пока моё мнение, что в симфони это решение порочно.
Даже если там всё происходит через перегенерацию кода класса, то система никак без полной интерпретации логики не поймёт, нужна ли мне заполненная зависимость в параметре конструктора, или нет.
Также параметр зависимости в конструкторе подразумевает какое-то хранение в свойствах класса и тут ты опять получаем лишний код.
В нормальной системе, в параметрах конструктора, только то, что нужно именно в конструкторе объекта.
В общем как ни крути, а преимуществ этому не вижу.
Непонятно что ускоряет, если генерируется экземпляр класса, то происходит и создание всех зависимостей. Но по логике бывает, что они не всегда нужны все сразу.
Более правильным подходом кажется создание объектов в местах их использования.
в Laravel это делается например так:
Честно, не убедительные доводы. Зашёл почитать ну какую-то конкретику, вроде удобства перегрузки классов ядра.. Вместо этого пишут про репутацию и стоимость.
У меня не было много опыта в Symfony, но мне показалось что этот инструмент сильно раздут, для большинства проектов он не очень подходит. Нет какого то мифического удобства в сравнении с той же Laravel, там более лаконичный синтаксис.
Не нравится в Symfony передача зависимостей через конструктор. Почему-то вообще не заходит и этот код кажется в классе лишним.
Помню там ещё была какая-то сложная валидация и мутная doctrine, но может быть она и неплоха, не сильно знаком со всеми фишечками.
Symfony можно описать как фреймворк монолитов. Из плюсов можно выделить компонентную основу. Благодаря ей компоненты можно использовать в других фреймворках, иногда это требует написание специфических адаптеров.
Если в компилируемом PHP появится что-то вроде горутин, + асинхронные драйвера к бд. То это может стать ультимативной комбинацией, которая остановит популярность многих языков, вроде Python и Golang.
Использую composer совместно со своим gitlab сервером, все legacy-библиотеки перевёл в отдельные репозитории, на остальные сделал форки, опять же в своём gitlab сервере.
Хук можно поставить на операцию начала, или отката транзакции, наверно это не такие частые процедуры.
Странно что удалось обойти антивирус при создании процесса,. у него итак есть хуки на все функции, наверное тут чуть поменяют алгоритм и всё заработает.
Да, так и сделаю, у меня есть цель вообще привлечь кого-то ещё к этому проекту, так как, сил одного разработчика для такого проекта маловато.
Помогает что до этого было 1.5 года разработки и сейчас идет просто обратный реинжиниринг.
Если архитектура будет открытой, то в идеале можно будет разработать какие-то общие микросервисы, сделать некий банк микросервисов…
Разработка пока на собственном гитлабе, в общих чертах что-то работает, на выходных наверно переложу на github, скину сюда ссылку.
К сожалению разработка фреймворка была в рамках коммерческого проекта, согласно договору не могу делиться кодом.
Собственно, по этой причине работаю над второй версией, она будет открытой, и гораздо более доработанной.
Основная идея в том, что если мы работаем с сервисом через HTTP то получаем JSON, если же микросервисы используются в неком существующем сайте на PHP, то отправляя запрос с экшена, мы уже получаем то, что возвращается по существу, а не JSON. При этом м-сервис остается независимым, у него даже может быть собственный хост.
Подобный подход видел в SocialEngine, но там не было микросервисной архитектуры.
«Огрызок» накидал за 5 минут, в нем действительно есть 1 экшен который возвращает объект по id, это как ни странно и есть объявление микросервиса, только без настроек.
Ну, речь то про PHP шла, конечно, если если вы написали отдельный сервис на Go при его использовании на стороне микросервиса необходим некий дополнительный инструмент, что-то вроде API адаптера, пока таких задач не возникала, но была обратная задача. Скажем так некая среда сайта не PHP, использовала мои микросервисы через API которое работает по умолчанию.
По поводу «абсурдности», думаю вы просто ещё не знакомы с приведенной архитектурой. У микросервиса в фреймворке, стеки технологий у каждого остаются свои, но есть некие требования, это использование фреймворка и загрузка ядра, а дальше может быть всё что угодно, любые библиотеки, компоненты подключение в микросервисе. Просто чаще всего нет никакой необходимости писать обработчик запросов для каждого микросервиса свой, работа с данными она тоже везде практически одинакова. Фреймворк хоть и компактен, но в нем есть собственная ORM, DI, логирование, обработка запросов и ошибок.
Возможно к зиме выкачу вторую версию, опишу на хабре, любопытно узнать, что вообще люди думают о таком подходе.
Вы наверно намекаете на меж-микросервисное взаимодействие,. так оно тоже реализовано на стороне фреймворка.
Используется обработчик событий, паттерн обсервер.
Если я обращаюсь к какому-нибудь репозиторию, который описан в другом микросервисе, то подключение ресурсов этого микросервиса произойдет автоматически, есть так же ручное подключение ресурсов, в общем проблемы нет.
Позволю не согласиться с Вами, всё зависит от программистов и от их навыков.
Подходя к задаче массовых микросервисов, написал с коллегами специальный фреймворк, для построения микросервисов, вот пример построения на нём микросервиса, согласитесь не выглядит громоздким.
Где-то в начале 2к годов, был на собеседовании по CPP,.. прошёл, но пообещали мало платить. Тогда помню, это так на меня повлияло, что даже основной стек поменял на веб. Сейчас смотрю, годы идут, а там похоже ничего не меняется.
Могу со стороны себя сказать, нет, программисты обычно так сконцентрированы на решении задач, что им нет никакого дела понимать проблемы продажников и пр. очень нужных сотрудников.
Все фабрики генерируемых классов, различные мидлвэры прописываются в конфигах, а сервис локатор последовательно использует эти настройки при генерации объекта.
Если делать объекты через new, то это засоряет код, а если кода много, то становится максимально неудобно.
Также если вам потребовалась для обработки гора параметров в классе, то это уже невалидный код и так писать не надо. Логику обработок можно раскидать по тем же мидлверам/фабрикам. Действуя принципам SOLID 1 класс 1 задача, что по итогу будет класс оперирующий высокоуровневой логикой.
Параметры в конструкторе класса на этом фоне выглядят мягко-говоря лишними, только добавляющими сложности при создании объекта.
Если нужны параметры, используйте сеттеры и валидаторы.
В конструкторе прописаны зависимости, как параметры. Когда создаётся объект, подразумевается, что параметры должны быть заданы.
Не помню точно, как в Symfony реализация, но если взять для примера Magento 2 (там тоже передача зависимостей через конструктор), то там происходит генерация параметров конструктора и подстановка в вызов. И даже если параметры потом ансетить, это всё равно лишние операции, лишняя логика.
Как нибудь будет время посмотрю подробнее этот процесс, но пока моё мнение, что в симфони это решение порочно.
Даже если там всё происходит через перегенерацию кода класса, то система никак без полной интерпретации логики не поймёт, нужна ли мне заполненная зависимость в параметре конструктора, или нет.
Также параметр зависимости в конструкторе подразумевает какое-то хранение в свойствах класса и тут ты опять получаем лишний код.
В нормальной системе, в параметрах конструктора, только то, что нужно именно в конструкторе объекта.
В общем как ни крути, а преимуществ этому не вижу.
Более правильным подходом кажется создание объектов в местах их использования.
в Laravel это делается например так:
Честно, не убедительные доводы. Зашёл почитать ну какую-то конкретику, вроде удобства перегрузки классов ядра.. Вместо этого пишут про репутацию и стоимость.
У меня не было много опыта в Symfony, но мне показалось что этот инструмент сильно раздут, для большинства проектов он не очень подходит. Нет какого то мифического удобства в сравнении с той же Laravel, там более лаконичный синтаксис.
Не нравится в Symfony передача зависимостей через конструктор. Почему-то вообще не заходит и этот код кажется в классе лишним.
Помню там ещё была какая-то сложная валидация и мутная doctrine, но может быть она и неплоха, не сильно знаком со всеми фишечками.
Symfony можно описать как фреймворк монолитов. Из плюсов можно выделить компонентную основу. Благодаря ей компоненты можно использовать в других фреймворках, иногда это требует написание специфических адаптеров.
Если в компилируемом PHP появится что-то вроде горутин, + асинхронные драйвера к бд. То это может стать ультимативной комбинацией, которая остановит популярность многих языков, вроде Python и Golang.
Есть ещё физиология, которую не обманешь. У меня например после более 20 лет опыта в разработке стала хуже память, скорость мышления замедлилась итд.
При поиске работы, если у меня раньше, лет 10 назад было по 10 оферов за пару недель, то сейчас 2-3.
Чуть не всех пугает, если видят количество рабочих мест больше 20. Сложно убедить что это нормально приходится скрывать о себе часть информации.
В общем к 40 годам возраст становится проблемой для разработчика.
А я 15 лет назад им пользовался, удивительно, что столь старый инструмент стал "сенсацией".
Странно что удалось обойти антивирус при создании процесса,. у него итак есть хуки на все функции, наверное тут чуть поменяют алгоритм и всё заработает.
github.com/wdforge
Пока только деланы наброски: ServiceManager и EventManager.
Помогает что до этого было 1.5 года разработки и сейчас идет просто обратный реинжиниринг.
Если архитектура будет открытой, то в идеале можно будет разработать какие-то общие микросервисы, сделать некий банк микросервисов…
Разработка пока на собственном гитлабе, в общих чертах что-то работает, на выходных наверно переложу на github, скину сюда ссылку.
Собственно, по этой причине работаю над второй версией, она будет открытой, и гораздо более доработанной.
Основная идея в том, что если мы работаем с сервисом через HTTP то получаем JSON, если же микросервисы используются в неком существующем сайте на PHP, то отправляя запрос с экшена, мы уже получаем то, что возвращается по существу, а не JSON. При этом м-сервис остается независимым, у него даже может быть собственный хост.
Подобный подход видел в SocialEngine, но там не было микросервисной архитектуры.
«Огрызок» накидал за 5 минут, в нем действительно есть 1 экшен который возвращает объект по id, это как ни странно и есть объявление микросервиса, только без настроек.
По поводу «абсурдности», думаю вы просто ещё не знакомы с приведенной архитектурой. У микросервиса в фреймворке, стеки технологий у каждого остаются свои, но есть некие требования, это использование фреймворка и загрузка ядра, а дальше может быть всё что угодно, любые библиотеки, компоненты подключение в микросервисе. Просто чаще всего нет никакой необходимости писать обработчик запросов для каждого микросервиса свой, работа с данными она тоже везде практически одинакова. Фреймворк хоть и компактен, но в нем есть собственная ORM, DI, логирование, обработка запросов и ошибок.
Возможно к зиме выкачу вторую версию, опишу на хабре, любопытно узнать, что вообще люди думают о таком подходе.
Используется обработчик событий, паттерн обсервер.
Если я обращаюсь к какому-нибудь репозиторию, который описан в другом микросервисе, то подключение ресурсов этого микросервиса произойдет автоматически, есть так же ручное подключение ресурсов, в общем проблемы нет.
Подходя к задаче массовых микросервисов, написал с коллегами специальный фреймворк, для построения микросервисов, вот пример построения на нём микросервиса, согласитесь не выглядит громоздким.