Чем грозит синглтон для БД?

#php #singleton

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

Сейчас использование БД выглядит так:

# Установка соединения (срабатывает только в первый раз)
DB::set('host','db_name','login','pass');
# Получение PDO объекта для взаимодействия
DB::get();


В классах работающих с БД для уменьшения связанности создаю приватную статическую
переменную которой присваиваю DB::get().
Рассчитываю на то, что в случае если способ получения PDO объекта изменится, мне
придется сменить только значение этой самой переменной в каждом классе работающем с БД.

Чем плох такой подход и чем он грозит при разрастании проекта?
Имеет ли смысл заводить реестр если таких объектов станет больше двух-трех?
    

Ответы

Ответ 1

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

Попробуем потеоретизировать.

1. Что будет, если добавится ещё одна база данных?

Придётся добавить некий новый статический класс DB2 и соответствующие методы DB2::set()
/ DB2::get(). Соответственно, в классах, которые используют оба подключения, придётся
добавлять новую статическую переменную.

2. Что будет, если понадобится писать тесты для компонентов, использующих БД?

Придётся полагаться на то, что где-то там внутри компонентов вызов DB::get() сработает
правильно. Мы не будем иметь доступа к инстансу соединения с БД, чтобы заменить его
каким-нибудь fake-объектом для отдельного тестового случая. 

3. Что будет, если добавится несколько других точек входа в код?

Например, помимо основного сайта появятся: API для мобильных приложений, консольные
демоны, админская часть, личный кабинет партнёров. В этом случае придётся при инициализации
каждого приложения вызывать DB::set() с параметрами подключения. То есть множество
приложений окажутся завязанными на один единый синглтон. Вместо этого хотелось бы иметь
конфиг подключения, который независимо используется каждым приложением. Ведь гипотетически
прослойка для подключения к БД в них может быть разная.



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


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


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