Как хранить подключение к БД для удобного обращения из других классов без глобальной переменной?

Question

[LionG]

Хочу полностью отказаться от глобальных переменных. Создаю экземпляр класса DB и нужно к нему обращаться из остальных классов приложения.

На самом деле это может быть не только бд но и другие общие переменные... что то вроде "хранилища" типа как Vuex в Vue.

Comments

[Максим Федоров]

Вам нужен di container
Который будет хранить connection и отдавать его тем сервисам, которым он нужен (в конструктор, само собой)

[LionG]

Максим Федоров, Тащить все сервисы по отдельности из "Приложения" по цепочке вниз реально боль особенно с учетом что вложенность неограниченна. И где то на 99 уровне потребуется внедрить новый сервис))

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

Не могу разобраться как в таком случае должен работать контейнер (php-di). Вот запрашиваю я у контейнера "Приложение" что бы его запустить, в самое приложение контейнер может передать сервис BD если указать его в конструкторе, а дальше как ? В роутер уже только вручную передавать и тут смысл контейнера ломается...

Сервисы
	BD
	Service0
	Service1
	Service2

Приложение

	new Роутер (маршрут, аргумент)

		switch (маршрут)

			new Маршрут0 (аргумент)

			new Маршрут1 (аргумент)

				switch (аргумент)
					new A
					new B
					new C
						тут нужна BD и Service1
						...
					new D
						тут нужен Service0 и Service2
						...
					...
			new Маршрут2 (аргумент)
			...

	new SomeClass
		A
			B
				C
					тут тоже нужна BD
	...

[FanatPHP]

Это все делает контейнер.
он видит, что а нужен бэ, и создает его
создавая бэ он видит, что ему нужен цэ
создавая цэ, он видит что ему нужна бэдэ,
создает и инстанцирует её

[LionG]

FanatPHP, Если указывать сервис в аргументах конструктора то контейнер его отработает. А как работать например с роутером ? Он создается вручную и принимает доп аргументы и по цепочке ниже кому то потребуется BD.

И что если в BD нужно тоже передать аргументы ? Те же данные для подключения. Нужно вручную создать и добавить в контейнер BD и потом вызвать приложение ?

[FanatPHP]

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

[LionG]

FanatPHP,

class DB {
    public $connection = 'ok';
}

class Worker {
    public function __construct(DB $db, $i) {// как получить тут DB от контейнера и аргументы от workerManager ?
        echo "Worker $i connection is $db->connection";
    }
}

class App {
    public function __construct() {
        //new Router...
        //new workerManager...
        for ($i = 1; $i <= 10; $i++) {//тут может быть foreach со списком задач
            //10 воркеров с разными аргументами...
            new Worker($i); //конструктор требует DB + аргументы... а значит получить DB от Route0 и так по цепочке до App где DB можно получить в конструкторе что убивает смысл di. Или нужно подключать Router как зависимость в App, workerManager как зависимость в Router и через workerManager получать все зависимости и отправлять их в new Worker ? Но опять же Router нужно тоже через new создавать что бы передать ему динамические аргументы.
        }
    }
}

Или я вообще не правильно di понимаю и пытаюсь им сделать то что он не может ?) Тогда как мне передать DB в воркеры без глобальных переменных и контекста через все приложение ? В js с import'ами такое намного проще реализовывать))

[FanatPHP]

если ты создаешь воркеры руками, то руками диби и передавай

[LionG]

FanatPHP, В итоге возвращаемся к началу тк это может быть не только DB а еще N+ зависимостей и N+ уровней углубленности где нужно будет "руками передавать".

Тогда опять возвращаюсь к идее прокидывания "контекста" через все классы уровней из которого я смогу запрашивать зависимости, только наверное не контекст а контейнер. И не приложение запускать через контейнер, а контейнер запускать в приложении и использовать его только для запроса зависимостей.

[FanatPHP]

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

[FanatPHP]

Вообще я наверное наврал
попросить контейнер создать нужные классы руками тоже можно.
Это странно, но можно в данном случае.
Описываешь, какие зависимости нужны твоим классам, и вперед

[LionG]

FanatPHP,

Описываешь, какие зависимости нужны твоим классам, и вперед

Через Inject аннотациями ?

/**
     * Explicit definition of parameters by their name:
     *
     * @Inject({"db" = "DB"})
     */
    public function __construct(DB $db, $i) {
    }

Не прокатывает или я неправильно создаю объект через new.

[FanatPHP]

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

[LionG]

FanatPHP,

require './vendor/autoload.php';

    $builder = new \DI\ContainerBuilder();
    $builder->useAnnotations(true);
    $container = $builder->build();

    $container->make('App\App', [
        'con' => $container
    ]);

class DB {
    public $connection = 'ok';
}

class Worker {
    public function __construct(DB $db, $i) {
        echo "Worker $i connection is $db->connection";
    }
}

class App {
    public function __construct($con) {
        for ($i = 1; $i <= 10; $i++) {
            $con->make('App\Worker', [
                'i' => $i,
            ]);
        }
    }
}

Работает. Вот только контейнер теперь нужно передавать через все уровни.

[FanatPHP]

КАКИЕ ЕЩЁ УРОВНИ?!!!!
ЗАЧЕМ?!
Это идиотизм.
В воркер надо передавать объект, который работает с воркером.
Если у воркера есть своя зависимость, то ее контейнер ему создаст. Если у той зависимости есть своя - е тоже создаст. В итоге воркер имеет все что ему нужно, без всякой сквозной канализации

Какой говнокод у тебя работает напрямую с БД, а не через модель?

Блин.
Ну если ты не понимаешь ООП - то нафига тебе вообще все эти контейнеры, объекты, автолоады?
говнякал бы и дальше процедурщиной и жлобалсами и горя не знал

[LionG]

FanatPHP, =D БД это условность, это может быть любое стороннее приложение или сервис который должен существовать в единственном экземпляре объектом.... проще всего привести пример на подключении к бд где нельзя не согласиться что оно должно быть одно.

Контейнер добавляет зависимости до тех пор пока я не создам какой нибудь объект через new что бы передать в него аргументы, а дальше механизм внедрения зависимостей ломается тк они внедряются только через аргументы конструктора и приходится передавать их "вручную". Вот и получаются уровни - 1) App 2) Router 3) Worker. А "канализация" нужна что бы не вести "вручную" 100 зависимостей с 1го использования new (Router) до нужного объекта (Worker).

В воркер надо передавать объект, который работает с воркером.
Если у воркера есть своя зависимость, то ее контейнер ему создаст.

В том то и проблема что контейнер не может создать DB для воркера когда тот создается через new (а его по другому и не создать тк нужно передать аргументы). А если вы имеете ввиду $con->make то $con и есть та самая "канализация" которая идет App -> Router что бы создать Worker, а если в воркере нужно что то создать у чего есть зависимость то и туда нужно передать $con.

Если у вас есть другие менее говнокодные варианты почему бы вам просто не поделиться ими ?

[FanatPHP]

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

[0x131315]

LionG, даже такой случай как смешанное конструирование разобран в официальной документации)
Просто изучи её подробнее, там всё есть.

[FanatPHP]

Через нью создаешь только те объекты, у которых нет зависимостей
Если при работе надо создать объект, который требует зависимости, то он создается фабрикой.
у которой внутри уже есть все зависимости, которые ей туда положил контейнер

Answer 1

[0x131315]

Пора освоить внедрение зависимостей.
https://m.habr.com/ru/post/350708/comments/#commen...
Это такие штуки, которые сами подставляют в конструктор класса требуемые ему зависимости.
Например можно взять php-di пакет в composer.

Comments

[LionG]

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

[0x131315]

LionG, так в чём проблема?
Опиши в конфиге фабрику, которая и соберёт тебе объект с любыми параметрами и по любым условиям.
В ней можно использовать любой код и любые другие зависимости (которые опять же разрешит сам контейнер по инструкциям из конфига), или данные из любых объектов - в общем полная свобода.

Да и без фабрики оно умеет не только любые аргументы в конструктор прокидывать, но и вызывать сеттеры, и даже перезаписывать поля объекта - там активно используется reflection api под капотом. Т.е. через неё можно настроить абсолютно любой объект, даже если автор не предусмотрел его настройку через сеттеры или конструктор, а сам код по какой-либо причине (например это чужая библиотека) менять нельзя. На оффсайте php-di есть примеры на все случаи жизни.

В том то и ценность этой штуки, что она полностью избавляет от таких цепочек зависимостей, позволяет их "развязать", получив хороший чистый код.
В статье из моего предыдущего коммента это раскрывается.

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

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

Что совсем замечательно, можно прийти к практике в качестве зависимостей указывать не классы, а вообще только интерфейсы, а конкретную реализацию выбирать в конфиге, причем в том числе динамически: этот объект получит файловый логгер, а этот вот пусть в кибану логи пишет.

[Федор Тетерников]

0x131315, вопрос не как создать объект, вопрос в том, куда и как обратиться чтобы этот объект получить. К примеру, есть код:

<?php

Class DB {
	public function get() {
		return 'getDB';
	}
}

function db() {
	return new DB();
}

Class A {
	public function getB() {
		$b = new B();
		return $b;
	}
}

Class B {
	private $db;
	
	public function __construct() {
		$this->db = db()->get();
	}
}

$a = new A();
$b = $a->getB();

var_dump($b);

В классе А нет нужды подключать DB, в классе B подключаем DB через глобальную функцию. Как это должно выглядеть с DI-контейнером, т.е. каким образом мы должны обращаться к нему из класса B чтобы получить DB? Можете, пожалуйста, пояснить?

[FanatPHP]

Федор Тетерников,
Тут фокус в том, что мы не создаем объекты руками через new.
И мыслим не отдельными объектами, а конкретным функционалом.
В А мы передаем тот функционал, который нам создаст экземпляр объекта Бэ

Самый тупой пример: контроллер принципиально не работает с БД.
С БД работает модель. Но модель мы вызываем из контроллера. Как быть? Вот он твой случай.

И тут нам DI, при создании экземпляра контроллера, и передаст в него нужную модель.
У которой внутри уже будет подключение к БД.
И которая нам вернет какой-нибудь DTO, создав его сама.

То есть в ООП мы на самом деле мыслим не отдельными классами, а функционалом. Не "я хочу такой объект создать в А", а "я хочу такой-то функционал получить в А"
А этот функционал уже сам говорит DI, какой функционал, какие зависимости ему в свою очередь нужны для работы. DI их прилежно создает. И так по цепочке, до самых первичных объектов типа соединения с БД, логгера и пр.

[LionG]

Федор Тетерников,

require 'vendor/autoload.php';

(function() {
    $builder = new \DI\ContainerBuilder();
    $builder->addDefinitions([
        'db.host' => 'localhost',
        'db.user' => 'root',
        'db.pass' => 'password',
        //инструкция о том как создавать объект DB
        'DB' => DI\create()->constructor(DI\get('db.host'), DI\get('db.user'), DI\get('db.pass')),
    ]);
    $container = $builder->build();
    //просим контейнер создать объект A
    $a = $container->get('A');
    $b = $a->B;
    var_dump($b);
})();

Class A {
    public $B;
    //контейнер видит что объекту A нужен объект B и создает его
    public function __construct(B $b) {
        $this->B = $b;
    }
}

Class B {
    private $db;
    //контейнер видит что объекту B нужен объект DB и создает его
    public function __construct(DB $db) {
        $this->db = $db;
    }
}

Class DB {
    private $connection = 'connection';
    //контейнер не знает что подставить в конструктор DB поэтому для него нужно оставить инструкцию в addDefinitions
    public function __construct($host, $user, $pass) {
    }
    public function get() {
        return $this->connection;
    }
}

[Федор Тетерников]

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

[Федор Тетерников]

FanatPHP, спасибо, это в принципе понятно, мне просто нужен был пример, без него некоторые моменты неправильно понимал и картинка не складывалась.

Answer 2

[FanatPHP]

Вопрос сложный.

Правильный ответ: передавать в конструктор класса.
Всякие "хранилища" - это костыли, не сильно лучше жлобалсов.

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

Тут фокус в том, что мы не создаем объекты руками через new.
И мыслим не отдельными объектами, а конкретным функционалом.
В А мы передаем тот функционал, который нам создаст экземпляр объекта Бэ

Самый тупой пример: контроллер принципиально не работает с БД.
С БД работает модель. Но модель мы вызываем из контроллера. Как быть? Вот он твой случай.

И тут нам DI, при создании экземпляра контроллера, и передаст в него нужную модель.
У которой внутри уже будет подключение к БД.
И которая нам вернет какой-нибудь DTO, создав его сама.

То есть в ООП мы на самом деле мыслим не отдельными классами, а функционалом. Не "я хочу такой объект создать в А", а "я хочу такой-то функционал получить в А"
А этот функционал уже сам говорит DI, какой функйионал, какие зависимости ему в свою очередь нужны для работы. DI их прилежно создает. И так по цепочке до самых первичных объектов типа соединения с БД, логгера и пр.

Comments

[LionG]

Во многих проектах оно так и передается - через конструктор, но часто встречается что нужно передать кучу сервисов или они добавляются в процессе и это вот неудобно... например что бы передать сервис из класса A0 в класс F3, придется передавать его через B C D (с учетом что этот сервис может понадобиться потом еще и в B4 например). Проще 1 раз проложить "магистраль" в которой как раз и будут все данные, а классы будут забирать только нужные объекты из этой "магистрали".

Или есть еще такая идея - это зациклить приложение. те передавать в качестве "магистрали" ссылку на точку входа в приложение - объект класса А и в корне приложения проинициализировать все нужные сервисы в том числе и BD.

[FanatPHP]

Ну вот ты со своей "магистралью" дошел до того, до чего авторы фреймворков дошли 10 лет назад. CI, yii, вот это вот все. Только они все уже давно от этого отказались.

Только непонятно, чем твоя магистраль отличается от жлобалсов. ну то же самое же, только не отдельные переменные, а одна большая свалка. Ну офигеть какое улучшение.

Answer 3

[rPman]

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

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

class Main
{
  public $db; // само собой можно геттеры сеттеры делать или сами методы по работе с базой тут определить
}
class Work
{
  function __construct($main)
  {
    $this->main=$main;
  }
  function do()
  {
    $this->main->db->connect(...)
  }
}

Comments

[FanatPHP]

те же овоиды, только в профиль

[LionG]

Только что выше в комменте такое подумал))

[rPman]

FanatPHP, не важно как ты это оформишь, кто то где то должен это хранить
не считаю god-класс для подобной задачи антипаттерном, это контекст выполнения, пусть будет таковым

иначе придется тщательно раскладывать переменные по мелким классам веточкам, а потом вспоминать, где ты их оставил, и выковыривать их через вложенные вызовы

[FanatPHP]

нету уже никаких год объектов. даже авторы yii поняли что их App - это большая помойка с прибитыми гвоздями зависимостями, и в 3 его нет. yii2 - последний живой фрейморк где такой подход еще используется

[batyrmastyr]

FanatPHP, а как же хелперы ларавеля?