Когда платят за количество строчек кода, конечно надо все вручную пробрасывать. В остальных случаях выгоднее автовайрить.

так зачем UserRepository должен быть сервисом то? для autowire вполне достаточно знания о том, что нужен UserRepository

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

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

да, почему нет?!

Ну как бы смысл сервисов в том что они билдятся из зависимостей и лежат в контейнере.

Если у тебя 10 классов требуют репозиторий, у тебя он 10 раз будет инстанциироваться?

зависимость от UserRepository указана

Если 1 раз, а остальные 9 он будет браться из кеша, то по сути он и будет валяться в контейнере как сервис.

Кроме того, если задротить в ООП то в конструкторе надо указывать UserRepositoryInterface :) А в контейнере уже будет определяться, какой класс в этот интерфейс вставляется.

Если 1 раз, а остальные 9 он будет браться из кеша, то по сути он и будет валяться в контейнере как сервис.

с каких пор создание обьекта стало дорогой операцией?

с каких пор создание обьекта стало дорогой операцией?

С таких когда скрипт работает под хойлоадом

и эти объекты создаются тысячами каждый раз для использования.

Кроме того, если задротить в ООП то в конструкторе надо указывать UserRepositoryInterface :) А в контейнере уже будет определяться, какой класс в этот интерфейс вставляется.

интерфейс чтобы найти свою единственную реализацию - ну ок...

и эти объекты создаются тысячами каждый раз для использования.

пхп создан умирать - stateless же

так вот именно, придет новый запрос - опять все по новой тысячами будет создаваться.

Так хотя бы сервис будет построен 1 раз за запрос.

Ну и в приличном приложении в контейнере валяется например 1000 сервисов.

Ну и в приличном приложении в контейнере валяется например 1000 сервисов.

1000 сервисов - 9 репозиториев = почти 1000

репозиторий же интерфейсом и представлен, а как иначе, это же персист часть, а значит твой аппликейшн должен зависеть от интерфейса, который уже в персист слое реализуется

@nanowire будет жить. Поприветствуем!

@paraschakva будет жить. Поприветствуем!

@Diwate будет жить. Поприветствуем!

@kovy17 будет жить. Поприветствуем!

#вакансия #телеграмбот Приветствую. Извиняюсь, если не по адресу. У нас есть проект на разработку бота, кому интересно, пишите. Город: мы находимся в г.Новосибирск Формат работы: удаленно Занятость: проектная Оплата: от 10 до 50т.р. Описание вакансии: Требуется разработчик на проект поддержки и доработки телеграм-бота на PHP. Написан не очень чисто, поэтому важно умение разбираться в коде и наличие хотя бы минимального опыта. Название компании: Shark Develop Контакты: @kovy17

#вакансия #телеграмбот Приветствую. Извиняюсь, если не по адресу. У нас есть проект на разработку бота, кому интересно, пишите. Город: мы находимся в г.Новосибирск Формат работы: удаленно Занятость: проектная Оплата: от 10 до 50т.р. Описание вакансии: Требуется разработчик на проект поддержки и доработки телеграм-бота на PHP. Написан не очень чисто, поэтому важно умение разбираться в коде и наличие хотя бы минимального опыта. Название компании: Shark Develop Контакты: @kovy17

то есть наговнокодили, а теперь ищите человека, который это всё переделает, прекрываясь "поддержкой и доработкой"?

#вакансия #телеграмбот Приветствую. Извиняюсь, если не по адресу. У нас есть проект на разработку бота, кому интересно, пишите. Город: мы находимся в г.Новосибирск Формат работы: удаленно Занятость: проектная Оплата: от 10 до 50т.р. Описание вакансии: Требуется разработчик на проект поддержки и доработки телеграм-бота на PHP. Написан не очень чисто, поэтому важно умение разбираться в коде и наличие хотя бы минимального опыта. Название компании: Shark Develop Контакты: @kovy17

по правилам клуба должна быть вилка, или стоимость часа

иначе тут будет фриланс группа, но такого овна на просторах телеграмма достаточно, все равно криворукого найдете, потому что нормального по деньгам не потянете

Shark Develop Мобильный разработчик от 30 000 до 100 000 руб. можно сразу такие обьявления удалять, работорговцы подьехали

))

ths.chubaka будет жить. Поприветствуем!

то есть наговнокодили, а теперь ищите человека, который это всё переделает, прекрываясь "поддержкой и доработкой"?

Это же php, классическая ситуация.

привет, мб имели дело с сервисами тех поддержки, какой лучше в плане цена/качество?

@Gvixar будет жить. Поприветствуем!

Ситуацию в которой ты стал программистом html ничем не объяснить и не оправдать

упоролся шоле

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

Ладно

Без проблем

@DepthOfField будет жить. Поприветствуем!

@antontake будет жить. Поприветствуем!

Никак. Сериализация это про сохранение некоторых данных в строку и наоборот. Про выполнение кода там нет ничего. Это лучше в сторону eval посмотреть.

никак

если ты не по взлом, а по какие то действия после десериализации, то смотри __wakeup()

а какие плюсы есть в использовании сериализации? ведь все эти данные можно хранить в JSON строке.. ее и проще понять и обработать. да и символов для кодирования одних и тех же данных JSON использует меньше. Зачем же использовать именно сериализацию данных?

хранение в json это тоже сериализация

а какие плюсы есть в использовании сериализации? ведь все эти данные можно хранить в JSON строке.. ее и проще понять и обработать. да и символов для кодирования одних и тех же данных JSON использует меньше. Зачем же использовать именно сериализацию данных?

Сериализация PHP существовала ещё до изобретения JSON. Да и функции json_encode/json_decode появились лишь в PHP 5.2. Сейчас, конечно, JSON всем удобнее, но, например, внутренний механизм сессий PHP сериализует в формате php.

Сериализация (в программировании) — процесс перевода какой-либо структуры данных в последовательность битов. Обратной к операции сериализации является операция десериализации (структуризации) — восстановление начального состояния структуры данных из битовой последовательности.

а какие плюсы есть в использовании сериализации? ведь все эти данные можно хранить в JSON строке.. ее и проще понять и обработать. да и символов для кодирования одних и тех же данных JSON использует меньше. Зачем же использовать именно сериализацию данных?

а как ты json обратно в объект конкретного класса десериализуешь

а как ты json обратно в объект конкретного класса десериализуешь

не знаю.. никак) а для сериализированых данных не в JSON это можно?

угу, там имя класса сохраняется и он создается при десериализации