Разбор ООП с Delphinum

# L!MP (17.11.2016 / 14:54)
А, ну так фабрика это получается сервис провайдер.

Можно назвать и так.
За исключением, что ВСЕ зависимости она (фабрика) должна требовать из контейнера.

AlkatraZ, я там начудил с велосипедным ActiveRecord, вместо использования кошерного Doctrine, потому пришлось говнокодить

L!MP, в юнит-тестах нельзя ничего компилировать, ибо "паттерны xUnit". Короче сложно это все )

и для чего это все нужно? чтоб руками не писать вызовы нужного для работы чего то другого? то есть db зависит от config , а
user зависит от db

# Delphinum (17.11.2016 / 14:59)
L!MP, в юнит-тестах нельзя ничего компилировать, ибо "паттерны xUnit". Короче сложно это все )

Ну можно это делать заранее, гг.

Ладно, всем спасибо за диалог, пошел я за праздничный стол, гг, всем удачного буднего дня

# Delphinum (17.11.2016 / 14:57)
AlkatraZ, я там начудил с велосипедным ActiveRecord, вместо использования кошерного Doctrine, потому пришлось говнокодить

Я хоть и написал для Моби гейт Доктрины, но пока еще до сих пор сомневаюсь в целесообразности ее использования.
По ходу можно и запилить, тем более, что Доктрина может выдавать чистый \PDO объект в реализации Doctrine\DBAL\DriverManager
Но вот будет ли кто-то реально использовать ОРМ, тут вопрос. Но на всякий случай я предусмотрел решение, вдруг и самому потом стукнет в голову...

Koenig, SL решает две задачи:
1. Логика создания сервиса, будь то конфиги приложения или коннект к БД, аккумулируются в одном месте (в локаторе), а не размазываются по всему приложению, от чего с ними становится проще работать
2. Появляется возможность замени одного сервиса на другой без необходимости что то менять в исходниках

# Koenig (17.11.2016 / 15:01)
и для чего это все нужно? чтоб руками не писать вызовы нужного для работы чего то другого? то есть db зависит от config , а
user зависит от db

На примере нового Джона:

Тебе нужен текущий системный пользователь?
Просто пишешь:

/** @var Johncms\User $systemUser */
$systemUser = $container->get(Johncms\User::class);

не задумываясь откуда и как это берется. У тебя есть полноценный внутренний API, им (как разработчик модуля0 и пользуешься.

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

AlkatraZ, товарищ Эрик Эванс в своей книге "Проблемно-ориентированное проектирование" привел несколько задач, которые должны решаться на уровне приложения для записи и чтения из базы сущностей. Задачи довольно сложные в реализации, но очень важные. Кроме как Doctrine я не знаю инструментов в PHP, которые их бы решали.

Иными словами: ты знаешь, что у тебя есть контейнер. от которого ты можешь затребовать нужные данные, к примеру объект PDO::class
При чем, на самом деле тебе может отдаваться совсем другое, к примеру Доктрина, или что-то еще...
Но оно будет совместимо с PDO и должным образом проинициализировано.

Зачем ТЕБЕ беспокоиться о том, как в ядре реализована инициализация PDO?
Тебе важно знать, что это ЕСТЬ и ты это можешь получить от контейнера по запросу.