Разбор ООП с Delphinum

Кстати да, мы можем добавить в реализацию того же PDO какую нить прикладную логику (на пример запись в лог всех запросов в базу), а пользователь об этом даже не узнает и не нужно по всему приложению искать коннекты к БД через PDO и оборачивать их в проксирующий Logger, достаточно сделать это один раз в фабрике SL, которая отвечает за создание и отдачу PDO.

# Delphinum (17.11.2016 / 15:08)
товарищ Эрик Эванс в своей книге "Проблемно-ориентированное проектирование" привел несколько задач, которые должны решаться на уровне приложения для записи и чтения из базы сущностей

Ну эти "проблемы" стояли только перед уважаемым Эриком.
Ту же задачу зачастую намного проще можно решить и в рамках нативного PDO.
---
Это я разумеется утрирую, у ORM есть свои несомненные прелести.
Просто я не согласен с мнением, что какую-то задачу невозможно решить за рамками Доктрины, разве что, эта задача не была поставлена исключительно для самой Доктрины.

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

AlkatraZ, любую задачу можно решить без Doctrine, просто переписав у себя ее же логику ) но зачем, когда можно использовать Doctrine? Задачи действительно сложные и важны, в крупных проектах часто на них спотыкаешься и бьешься головой в попытках решить их.

AlkatraZ, то есть ты говоришь дай, а оно уже там само нужное вызовет и вернёт нужное, то есть вызов метода инициализации в контейнере

# Delphinum (17.11.2016 / 15:13)
Кстати да, мы можем добавить в реализацию того же PDO какую нить прикладную логику (на пример запись в лог всех запросов в базу), а пользователь об этом даже не узнает и не нужно по всему приложению и

Вот тут как раз и появляется преимущество конфиг-подхода и фабрик.
Пример: https://github.com/john-cms/jo ... hp#L6

Для контейнера я задаю ключ PDO::class
а значение - я могу прописать любое, главное, чтоб в итоге была реализация интерфейса PDO (иначе полетит совместимость).

Если к примеру, завтра вместо нативного PDO в Джоне захочется применить Доктрину, достаточно всего лишь в конфиге поменять одну строку.
вместо

PDO::class  => Johncms\PdoFactory::class,

написать

PDO::class  => Doctrine\DBAL\DriverManager::class,

AlkatraZ, совершенно так, с выходом PHP7 все разработчики просто требуют использовать ::class вместо каких нить строк, что не случайно, в двиге PHP начиная с 7 версии есть спец логика, которая умеет работать только с ::class и сильно ускоряет интерпретацию благодаря применению именно его, а не строки.

# Delphinum (17.11.2016 / 15:21)
AlkatraZ, совершенно так, с выходом PHP7 все разработчики просто требуют использовать ::class вместо каких нить строк, что не случайно, в двиге PHP начиная с 7 версии есть спец логика, которая умеет

Да и в DI контейнерах все главные разработчики настоятельно рекомендуют использовать вместо простых строковых ключей (это тоже возможно) их классовые аналоги.

Главное преимущество контейнера - фабрик - конфигов, это абстракция.
Разработчики ядра пишут свое, пейсатели модулей делают свое дело.

Главное - соблюдать интерфейс в виде КЛЮЧЕЙ контейнера. А реализация этих ключей может быть любая. При грамотном подходе, если (к примеру) я завтра заменю Zend на Symfony, разработчики модулей и сами модули этого не должны заметить

Более того, если соблюдается интерфейс Interop\Container\ContainerInterface то я могу применять ЛЮБОЙ DI контейнер, или сервис локатор, который реализует данный интерфейс. замена никаа не отразится на работе системы.

# AlkatraZ (17.11.2016 / 15:32)
Более того, если соблюдается интерфейс Interop\Container\ContainerInterface

почему Interop а не Psr (11)? Ты знаешь что то, чего не знаю я?