Как передать объект БД в класс?

Question

[Max Ba]

Мужики, запутался. Есть базовый класс App, в который должен быть передан объект БД PDO. У меня три варианта решения, но я чёт запутался с передачей, не пойму, какой лучше (верный), хотя работают все.
Вариант 1

class App{
  protected $db;
  public function __construct(){
    $this->db = new PDO('mysql:host=localhost;dbname=dbname', 'user', 'pass');
  }
}

Вариант 2

class App{
  protected $db;
  public function initDB(PDO $db){		
    $this->db = $d;
  }
}

class DB{
  public $db;
  public function instance(){
    $this->db = new PDO('mysql:host=localhost;dbname=dbname','user','pass');
    return $this->db;
  }
}

$app = new App();
$db = new DB();
$app->initDB($db->instance());

Вариант 3

class App{
  protected $db;
  public function initDB(PDO $db){
    $this->db = $d;
  }
}

class DB{
  public $db;
  public function __construct(){
    $this->db = new PDO('mysql:host=localhost;dbname=dbname','user','pass');
  }
}
$db = new DB();
$app = new App();
$app->initDB($db);

Answer 1

[ThunderCat]

Классический DI

class App{
  protected $db;
  public function __construct($db){
    $this->db = $db;
  }
}

Comments

[Max Ba]

Это тоже почти вариант 1. Спасибо)

[ThunderCat]

Макс Васильев, это вообще рядом не лежит с вариантом 1.
Класс передается по ссылке снаружи(то есть создается 1 раз и передается во все объекты где нужен, а не как в вашем случае создается новый экземпляр в каждом новом объекте). Так как это у вас реализовано - классический анитипаттерн.

[Max Ba]

ThunderCat, принял. Последний вопрос.. Вот так верно?)

class App{
  protected $db;
  public function initDB(PDO $db){
    $this->db = $db;
  }
}

class DB{
  public $db;
  public function __construct(){
    $this->db = new PDO('mysql:host=localhost;dbname=dbname','user','pass');
  }
}

$db = new DB();
$app = new App($db);

или так

$db = new PDO('mysql:host=localhost;dbname=dbname','user','pass');
$app = new App($db);

пардон за грубый "код", но вопрос как раз больше про объект базы данных
:)

[Max Ba]

ой. в App тоже конструктор

class App{
  protected $db;
  public function __construct($db){
    $this->db = $db;
  }
}

[ThunderCat]

Макс Васильев, первый вариант естественно работать не будет вообще, вы передаете в конструктор объект, но в коде класса конструктор не принимает никаких параметров, то есть сначала надо создать объект с пустым конструктором, затем вызвать метод initDB(), тогда по сути это будут очень близкие реализации, разница только методе передачи объекта ДБ внутрь апп. Оба варианта приемлемы, единственно что передача через конструктор это более короткий код и меньше операций. Единственно когда есть смысл использовать 2 вариант(с поправкой) это когда в конструктор нужно передать какие-то другие инициализирующие данные вместо ДБ.

[ThunderCat]

Макс Васильев,

ой. в App тоже конструктор

у вас все немного смешалось. Либо конструктор принимает БД, либо отдельный метод, а то так у вас вообще 2 метода делают одно и то же.

[Max Ba]

В целом, мне все понятно. Большое спасибо.

Answer 2

[Артур К.]

Зачем вам дополнительный объект DB? Если он нужен только для инициализации подключения к базе, то вы просто так расходуете память.
Фактически, вы сделали класс-обертку над PDO. Хотя в текущей реализации я не вижу в этом никакой необходимости.

Я бы не стал усложнять то, что без усложнения работает. Зачем городить лишние классы и объекты??
Идите от потребности. Надо контролировать создание подключения? — делайте initDB(), не надо контролировать, а объект всегда создается при объявлении App(), то и класс лишний не нужен.
Как кто-то сказал: "усложнять — легко, упрощать — сложно". Не усложняйте себе жизнь))

Comments

[Max Ba]

То есть это вариант 1?

[Алексей Скобкин]

Макс Васильев, Нет.

[Артур К.]

Макс Васильев, в текущих обстоятельствах, как вы описали, да — вариант 1.

[Алексей Скобкин]

Макс Васильев, Почитайте про SOLID. Особенно про SRP. В идеале ваш App ничего не должен знать об устройстве класса для работы с БД. А значит иницализация БД не должна в App происходить.
То есть можно взять третий вариант и доделать его. Ну и если App нужна БД для работы, то нет никакого смысла принимать её в App::initDb() вместо конструктора.

[Max Ba]

Алексей Скобкин, туго я что-то понимаю по последней фразе. (По остальному гуд)

никакого смысла принимать её в App::initDb() вместо конструктора.

То есть, вариант 2 вообще плохой? и если и делать, то как в третьем? ну +-

[Артур К.]

Алексей Скобкин, частично согласен. Но в данном случае, как я вижу устройство приложения, мы имеем дело с God-объектом.
Вся реализация БД уходит в руки PDO. Потому можно было бы сказать, что App и не знает ничего об этом. И опять возвращаюсь к исходному — лишнее усложнение в текущей реализации не нужно.

[Max Ba]

Артур Э., ну я экспериментирую) Сделал класс App, который соединяет по сути всё приложение. То есть в этот класс передается объект БД, массивы там всякие GET, POST. и уже дальше работает MVC.
Видать я запутался не с классом App, а с классом DB)
Вот это

class DB{
  public $db;
  public function __construct(){
    $this->db = new PDO('mysql:host=localhost.....');
  }
  return $this->db;
}
$db = new DB();
$app = new App($db);

эквивалентно этому?

$db = new PDO('mysql:host=localhost;....'); //просто, переменная
$app = new App($db);

?

[Артур К.]

Макс Васильев, фактически — да.
Если App в конструкторе просто достает значение переменной $db->db

class App{
  protected $db;
  public function __construct(DB $db){
    $this->db = $db->db; // Тут фактически объект PDO
  }
}

[Алексей Скобкин]

Артур Э., А я, вроде, и не предлагал оборачивать PDO во что-то пока нет необходимости. Ну и да, App тут тоже против SRP идёт. Но я отвечал автору вопроса с поправкой на выбранную архитектуру. Он изобретает свой Laravel, но можно было бы предложить ему изобрести свой Symfony :)

[Алексей Скобкин]

Макс Васильев, А зачем вы в классе DB делаете свойство $db публичным? Ну и return вне методов прямо в теле класса - это дичь какая-то.

[Max Ba]

Алексей Скобкин, не изобретаю, а разбираюсь) Каждый двиг сделан по своему. Реально они отличаются. Хотя бы реализацией.)))

[Max Ba]

Спасибо парни. Буду изучать дальше)

[Артур К.]

Алексей Скобкин, поддерживаю "архитектурную чистоту".
Только применительно к топику я бы и упростил всё максимально. Иначе, действительно, получится новый Laravel, с кучей огрехов))

Answer 3

[Павел Корнилов]

<?
class App{
  protected static $_instance;

  private function __construct(){
    return new PDO('mysql:host=localhost;dbname=dbname','user','pass');
  }

  # Singlton methods
	public static function getInstance()
	{
		self::$_instance = self::$_instance ?? new self;
		return self::$_instance;
	}

	private function __clone() {}

	private function __wakeup() {}
}

# Init
App::getInstance();
?>

lifeexample.ru/php-primeryi-skriptov/php-singleton...

Comments

[Max Ba]

Мне, как раз синглтон, не нужен) В рамках, даже простого ооп, это уже не актуально.

[Max Ba]

И да, у вас класс БД, а речь о классе - оболочке App.

[Павел Корнилов]

Макс Васильев, а может, вы просто не умеете их готовить? (с)

Чем вам синглтон не угодил как оболочка? Внутри него делаете статические методы, а потом обращаетесь к ним из ЛЮБОГО подключённого файла проекта, без всяких require. ИМХО, это очень удобно. А класс себе весело висит в памяти в единственном экземпляре.

Пример:

<?php
class App{
  protected static $_instance;

  private function __construct(){
    return new PDO('mysql:host=localhost;dbname=dbname','user','pass');
  }

  # Singlton methods
	public static function getInstance()
	{
		self::$_instance = self::$_instance ?? new self;
		return self::$_instance;
	}

	public static function useDB()
	{
		// Чего-то делаем с созданным экземпляром PDO, обращаясь к нему, как к self
	}

	private function __clone() {}

	private function __wakeup() {}
}

# Init
App::getInstance();

# Из любого файла вызываем метод обёртки на манер:
App::useDB();
?>

Это не удобно???

[Max Ba]

Павел Корнилов, Я такую же конструкцию и использую :) В проектах без ООП.
В классах, пробросить объект дело пары строк. И по моему сама идея синглтона особо не завязана конкретно на ооп.

[Павел Корнилов]

Макс Васильев, идея синглтона завязана на создании единственного экземпляра класса. То есть второй создать просто не возможно. Все обращения будут идти именно к нему.

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

Из минусов - пожалуй, только постоянное зависание в памяти сервера. Но, если использовать это с умом, это тоже можно превратить в плюс.

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

[Max Ba]

Павел Корнилов, пока что ооп оправдывает себя, особенно в моделях. Сейчас у меня тоже создан синглтон и я заметил, что это единственный объект, который живет своей жизнью, при том, что другие объекты отлично структурированы и взаимосвязаны.
На самом деле верная мысль, что нужно "уметь готовить". Не всегда одно и тоже в рамках разных проектов полезно.
Касаемо моего App, это оболочка, внутри доступен объект БД. он доступен всему приложению, аналогично глобальной переменной.

[Павел Корнилов]

Макс Васильев,

Касаемо моего App, это оболочка, внутри доступен объект БД. он доступен всему приложению, аналогично глобальной переменной.

Именно это я вам и предложил в своём решении.

[Max Ba]

Павел Корнилов, ))

[Алексей Скобкин]

Больше антипаттернов богу антипаттернов!

[Кирилл Несмеянов]

Павел Корнилов, подключение к БД не может быть синглтоном по определению. По очевидными причинам: Соединений к БД может быть несколько.

Answer 4

[hack504]

2 вариант нужен, если экземпляр класса DB будет ещё где-то использоваться помимо App. А также, если классы немного подкорректировать, то можно сделать LazyLoad подключение к БД в классе App.

Comments

[Max Ba]

Да не, как раз я и хотел в основном классе объявить (или передать из вне) объект бд и уже дальше передавать его в наследники.