Service Locator Repository injection with trait

[grigori]

объект а-ля DateTime может лезть в базу

Отличный аргумент, спасибо! Это надо исправить. Надо делать прямую декларацию зависимостей, без предположений.

зависимость от этого трейта и SL

От трейта - да. Вопрос был чуть выше насколько это критично. Не вижу чтобы это было важно для приложений.

SL надо сделать декларативным, и проблемы не должно быть. Как PHP-di, например.

проект «в себе», без возможности реиспользования

Реиспользовать надо компоненты и библиотеки. Приложения не надо повторно использовать, если это не коробочный продукт.
Можно использовать модель в нескольких местах в рамках одного приложения. Неважно как он создается - есть тактика API, и я собираюсь ему следовать.

появляется соблазн везде использовать $settings

Бороться с соблазнами - это что-то очень христианское. Ограничивать себя, чтобы говнокодеры не могли использовать код неправильно... Грустная картина. Бывает, неизбежно. Ярко, эмоционально, но совсем не по теме.

значения могут прийти как из настроек, так и из другого источника (от админа, юзера, etc.)

Логичный тезис. Вопрос - насколько актуальная эта проблема?
Я сторонник, дробления на stateless-микросервисы.
Если нужно несколько контекстов - давайте сделаем несколько приложений и свяжем их по API.
Бывают такие древние монстры, из которых невозможно просто взять и выпилить CRM. Я ориентируюсь не на них.

найти этого человека и объяснить ему кто он такой. Он гуляет от проекта к проекту

Мне кажется, некорректно переносить на меня грехи твоих коллег автоматически.
Мы не просто люди, мы инженеры. Давайте мыслить в рамках научного метода.
Отказываться ли от чего-то из опасений, что другие не поймут - зависит от проекта и характера. Помочь использовать правильно - нужно, сделаю.
Ограничивать как-бы чего не вышло - нет. Бороться надо с конкретными проблемами, а не за все хорошее. Иначе - майдан.

Спасибо за аргументацию. Теперь я могу доработать идею с учетом дельного замечания.

 

[Вурдалак]

Мы не просто люди, мы инженеры. Давайте мыслить в рамках научного метода.
Отказываться ли от чего-то из опасений, что другие не поймут - зависит от проекта и характера. Помочь использовать правильно - нужно, сделаю.
Ограничивать как-бы чего не вышло - нет. Бороться надо с конкретными проблемами, а не за все хорошее. Иначе - майдан.

Ты пытаешься выдать свои проблемы за наши проблемы. У меня никаких проблем с constructor injection нет.

 

[grigori]

Да, кэп. Это даже не проблема, это любопытство. Спасибо что уделил мне свое время и написал то, что заставило меня задуматься.

 

[AmdY]

@grigori если упрощать и отказываться от DI в пользу SL, то зачем вообще городить трейты с сеттером гетером. МОжно обчный статик сделать SL::get, SL::set, при желании можно из бэктрейса таскать вызываюзий класс и хитрохопо подменять зависимости. ПРосто и удобно, при этом функциональные возможности соизмерымы с DI

 

[grigori]

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

Я не думал о парсинге бектрейса, но сходу вижу только недостатки. Трейт - это легальная конструкция языка, которую я использую по назначению.

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

 

[fixxxer]

у меня есть еще много хороших идей

http://phpfaq.ru/humor/anecdotes#answer

 

[grigori]

ага, мне влом было ссылку искать