Как сделать автоподключение базы данных?

Question

[alexey_novorisov_89]

Есть самописная реализация MVC (только учусь), в моделях в конструктор передаю реализацию интерфейса, а не конкретный класс, соответственно, у меня возникает вопрос, как правильно сделать файл конфига с подключением к БД?
Я сделал файл config.php с константами, одна из которых содержит в себе дефолтное подключение к базе данных (попросту содержит в себе единственный класс для работы с БД - Mysql). Но PHP не позволяет содержать в константах объекты. Как лучше всего сделать подобный файл? Или может есть другие решения?
Глобальные переменные не рассматриваю равно как и не хотелось бы в каждый файл подключать конфиг который бы возвращал массив. Других решений не придумал/не нашел.

Comments

[Vitsliputsli]

Зачем объекты/классы в конфиге (и все таки класс или объект?)? Зачем в конфигурационном файле зависимость от реализации? Массива строк с необходимыми строковыми данными вполне достаточно, а уже на его основе создавайте нужные объекты. Посмотрите любой фреймворк.
Был бы пример, было бы интереснее.

[alexey_novorisov_89]

Vitsliputsli, объект.
Если честно, по поводу примеров, их нужно было бы слишком много.
Мой вопрос заключается в том, как сделать так, чтобы не подключать в каждой моделе модель конкретной БД (Мускл, постгре и т.д), а сделать что то общее?

Или просто сделать константу со значением конкретной бд ('mysql', 'postgres' и так далее) и if-ами в конструкте работы с бд разобрать ее и вернуть объект в зависимости от значения?

[Vitsliputsli]

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

[Антон Иванов]

alexey_novorisov_89, чтобы сразу делать правильно - МОДЕЛЬ не должна работать с БД. Модель - это лишь объект, перечисляющий "поля" таблицы БД. Работа с БД должна происходить в сервисном слое (например, Repository), в который вы один раз передаете параметры БД и строите подключение.

[Vitsliputsli]

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

[alexey_novorisov_89]

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

Вот примеры.
Класс с подключениями к разным базам (пока там только одна, большего и не надо):

<?php
namespace App\Models;

class DatabaseConnection
{
    public function mysqlConnection($host, $dbName, $login, $password): \PDO
    {
        return new \PDO("mysql:host=$host;dbname=$dbName", $login, $password,
            [
                \PDO::ATTR_ERRMODE => \PDO::ERRMODE_EXCEPTION,
                \PDO::ATTR_DEFAULT_FETCH_MODE => \PDO::FETCH_ASSOC,
                \PDO::ATTR_EMULATE_PREPARES   => false
            ]
        );
    }
}

Класс для Мускла:

<?php
namespace App\Models;

use App\Models\Interfaces\iDatabase;
use App\Models\DatabaseConnection;

class MySQLDB implements iDatabase
{
    public $dbConnection;
    private $query;
    
    public function __construct($host = 'localhost', $dbName = 'marketplace', $login = 'root', $password = 1111)
    {
        $this->dbConnection = (new DatabaseConnection)->mysqlConnection($host, $dbName, $login, $password);
    }

    /**
	 * SQL query into MySQL DB
	 * @param array query string
     * @param array placeholders
	 * @return \PDOStatement
	 */

    public function dbQuery(string $queryString, array $prepareData = NULL): \PDOStatement
    {
        if ($prepareData) {
            return $this->preparedQuery($queryString, $prepareData);
        }
        
        return $this->simpleQuery($queryString);
    }

    /**
	 * SQL prepared query
	 * @param array query string
     * @param array array with placeholders
	 * @return \PDOStatement
	 */

    private function preparedQuery(string $queryString, array $data): \PDOStatement
    {
        $this->query = $this->dbConnection->prepare("$queryString");
        $this->query->execute($data);
        
        return $this->query;
    }

    /**
	 * Simple SQL query
	 * @param array query string
	 * @return \PDOStatement
	 */

    private function simpleQuery(string $queryString): \PDOStatement
    {
        $this->query = $this->dbConnection->query("$queryString");
        return $this->query;
    }
}

И для примера модель, которая отвечает за таблицу 'cities' в базе данных (нужна только для регистрации в данный момент)

<?php
namespace App\Models;

use App\Models\Interfaces\iDatabase;

class Cities
{
    private $db;

    public function __construct(iDatabase $db = null)
    {
        $this->db = $db ?? DEFAULT_DB_CONNECTION; // ВОТ ТУТ
    }

    public function getAllCities(): array
    {
        return $this->db->dbQuery("SELECT * FROM cities")->fetchAll();
    }
}

Где капсом я написал "ВОТ ТУТ" должно осуществляться подключение, но так как вариант с константой отпал, эта строка нерабочая.
Ну а файл с конфигом нет смысла показывать, там раньше была константа DEFAULT_DB_CONNECTION в который хранился объект дефолтной базы (mysql), а сейчас все пусто.

[Vitsliputsli]

alexey_novorisov_89, что касается классов, если не брать мелочи, то, обёртка пока выглядит лишней, но для изучения норм, но все равно непонятно, зачем mysql чего-то там, у вас pdo и общение с драйверами уже универсализировано насколько возможно. Т.е. должна быть обёртка для pdo, а не mysql.
А "ВОТ ТУТ" это интересный вопрос, и он не про конфиги. Зависимости должны внедрятся - DI, вы же хотите их создать внутри (service locator, например), это антипаттерн. Т.е. либо не кошерно, но просто, например через service locator (его тоже не нужно совать в каждый класс, здесь он не нужен, перенесите на другой уровень), либо через какие нибудь хитрые DI контейнеры.

[alexey_novorisov_89]

Vitsliputsli, почему обёртка выглядит лишней? Просто я действовал по принципу, что в каждой моделе подключать ПДО по новой было бы лишним (как один из видов SRP в моем неопытном понимании), вот и вынес ее в отдельный класс.

Т.е. должна быть обёртка для pdo, а не mysql.

Да, я ошибся в формулировке, прошу прощения за ввод в заблуждение. Собственно, "строковая константа с названием СУБД" подразумевала разные подключения в пдо (там же не одно слово заменить, все-таки есть нюансы).
По поводу второго абзаца: я, если честно, очень долго вожусь с пониманием как архитектуры, так и принципов ООП (не просто голимое заучивание, а активное применение, чтобы на собеседовании было что показать банально), но в интернете ужасно мало информации с более практическими (реальными бекендовыми) примерами. Я, собственно, если бы не пытался отточить это дело, даже не парился бы по поводу этого вопроса, но я хочу разобраться, как и почему лучше, чтобы не приучать себя к неправильному.

Зависимости должны внедрятся - DI, вы же хотите их создать внутри (service locator, например), это антипаттерн.

Я, насколько понял из прочитанного в интернете, попытался инъекцию:

<?php
namespace App\Models;

use App\Models\Interfaces\iDatabase;

class Cities
{
    private $db;

    public function __construct(iDatabase $db = null)
    {
        $this->db = $db ?? DEFAULT_DB_CONNECTION;
    }
}

Моя логика следующая: есть одна единственная база данных mysql, ничего нового я дополнять не планирую, потому что проект учебный, но следует оставить плацдарм для масштабирования системы (ну вот а вдруг (+ принцип открытости-закрытости)), следовательно нужно сделать так, чтобы подключение было не жестким, а как бы в зависимости от ситуации. Исходя из того, что пока что я использую только mysql, то каждый раз при, например, создании объекта условной таблицы выше можно было написать:

<?php
namespace App\Controllers;

use App\Models\Cities;

class RegistrationController
{
    public function test()
    {
        $cities = new Cities();
    }
}

а не

<?php
namespace App\Controllers;

use App\Models\Cities;
use App\Models\MysqlDB

class RegistrationController
{
    public function test()
    {
        $cities = new Cities(new MysqlDB());
    }
}

Для решения этой проблемы я и сделал в конструкторе поле подключения БД изначально пустым, чтобы он автоматом подключался к дефолтной. Можете, пожалуйста, объяснить, почему это считается плохой практикой?

[Ипатьев]

Правильный ответ на вопрос с рабочим примером: https://qna.habr.com/answer?answer_id=1898879#answ...

Но сначала, конечно, надо понять базовые принципы - как работать с БД, ООП, MVC.
К примерй понять, что класс не должен сам решать, с какой БД он будет работать. А DEFAULT_DB_CONNECTION - это та же глобальная переменная, только с другого ракурса.

В общем, читать про внедрение зависимостей.

[Vitsliputsli]

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

public function __construct(iDatabase $db)
    {
        $this->db = $db;
    }
    ...
    $cities = new Cities($this->db)

Получается, что создав объект DB в одном месте, чтобы дотянуть его до потребителя, его придется тащить через конструкторы промежуточных классов. Что бывает не очень удобно. В какой-то степени проблема решается DI-контейнерами, при условии создании всех объектов сразу и возможности вытащить создание подобных объектов в самое начало.
То, что вы хотите сделать - это service locator. Не важно как вы организуете вызов, через глобальную переменную/функцию, через статическое свойство/метод. Не важно будете вы обращаться к конкретному классу/объекту или к контейнеру. Важно что вы обращаетесь к некому общему реестру и получаете объекты из него. Подход часто считают антипаттерном, хотя на мой взгляд, у него просто своя ограниченная сфера применимости. Для глобальных для всего приложения объектов он вполне подходит. Безусловно минусов у него хватает: вы привязываетесь к конкретному типу объектов, которые возвращает реестр, т.е. не сможете гибко менять этот объект (равно как и сам реестр). То, чего вы боялись, захочется сделать 2 коннекта к БД - нужно будет придумывать как это разруливать в каждом вызове service locator (хотя в большинстве задач коннектов к БД мало и это не представляет сложности). При тестировании может быть проблематично подменить объект запрашиваемый из service locator, но в вашем примере не проблема, т.к. сперва мы берем зависимость внедренную через конструктор. Также, обращения в service locator должны возвращать один и тот же объект, т.к. нельзя допустить создания новых объектов при каждом обращении.
Т.е. ваш вопрос совсем не про конфиги, а про зависимости объектов. Можно создать его в новой формулировке, вдруг что интересного напишут, тема не однозначная все-таки.

Answer 1

[rPman]

В вопросе сказано 'автоподключение', это значит в коде нет желания писать где то connect или аналогичную ему строку иннициализации.

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

И вот тут возникает вопрос о месте хранения настроек. Если для всего проекта предполагается одна база данных с одним одномоментным подключением, то значит настройки должны храниться глобально (в подавляющем большинстве случаев это отдельный подключаемый файл config.php с инициализацией констант в define) либо в конфигурационном файле, десериализаторов которых пруд пруди, используй хоть .ini (parse_ini_file) хоть .json хоть что угодно.

Я пользовался разок определением констант в виде статичных мемберов класса, подключаемых прямо внутри определения класса с помощью include (синтаксически это красивее define и не требует городить громоздкие уникальные имена)

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

function db()
{
  static $db=false;
  // до появления static у функций можно было хранить и запрашивать объект у самого класса статичным методом
  if(!$db) $db=new Database();
  return $db;
}

....

db()->query(...)

в этом случае подключение к базе будет сделано в момент первого доступа к ней, что иногда даже полезно