Использование одноэлементного класса базы данных в функциях и нескольких сценариях (PHP) — лучшие методы использования

Что-то из этого придется по вкусу. На работе мы также получаем дескриптор соединения ADODB через

$db = Registry :: getDB();

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

$name = Registry :: getDB()->getOne(
    "SELECT name FROM user WHERE user_id = ?", $userId
);

Использование реестра означает, что ваш вызывающий код имеет конкретную зависимость от вашего класса Registry. Это затрудняет тестирование вашего кода (лично это единственный раз, когда я бился головой о стену, используя реестр).

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

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

Лучшее объяснение DI и контейнеров (для PHP-разработчика), которое я видел, это Внедрение зависимостей Фабьена Потенсье в PHP 5.3 (начиная со слайда 9).

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

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

Я бы сказал, что вы на правильном пути!

Я использую суперглобальную переменную $GLOBALS для хранения соединения с базой данных. Творит чудеса.

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

Сейчас я надену беруши, готовый к стенаниям по поводу использования глобальных переменных!

@Downvoters - немного чтения перед сном:

Являются ли глобальные переменные плохими?

https://stackoverflow.com/questions/357187/global-variables-when-are-they-acceptable

Несколько цитат для вашего удовольствия:

«Глобальные переменные постоянно используются многими программистами. Сейчас мы называем их просто синглтонами.» — ДэнниСмурф

«Они полностью, принципиально, абсолютно, невероятно, поразительно злы.» — Винко Врсалович

И лучший ответ здесь от самого Клетуса: Являются ли глобальные переменные в PHP плохими упражняться? Если да, то почему?

Я имел дело с этим довольно много на протяжении многих лет. Я бы сказал, что добавление объекта, производного от Singleton, к суперглобальной переменной, такой как $_GLOBAL или $_SERVER, в первую очередь устраняет большую часть смысла создания класса Singleton.

Лучшей практикой, как я вижу, является доступ к нему, как вы предложили:

$result = Database_Class::singleton()->query('whatever');

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

function func() {
  $db = Database_Class::singleton();
  $db->query('insert into whereever');
  $db->query('insert into whereever');
  $db->query('insert into whereever');
  $db->query('insert into whereever');
}