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

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

8 голосов
/ 12 марта 2010

У меня есть одноэлементное соединение с БД, которое я получаю:

$ dbConnect = myDatabase :: getInstance ();

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

Очевидно, что я новичок, и я могу решить эту проблему 10 различными способами, ни один из которых не является действительно привлекательным для меня. Было бы намного проще, если бы я мог иметь эту переменную $ dbConnect доступную в любой функции без необходимости объявлять ее глобальной или передавать ее. Я знаю, что могу добавить переменную в массив $ _SERVER ... есть ли что-то не так с делая это? Это кажется мне несколько неуместным.

Еще один быстрый вопрос: это плохая практика:

$ result = myDatabase :: getInstance () -> query ($ query);

непосредственно из функции?

Ответы [ 4 ]

1 голос
/ 12 апреля 2010

Кое-что из этого придет по вкусу. На работе мы также получаем дескриптор подключения 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 вместо Реестра, он предоставляет элегантный и простой способ получить указатели на зависимости (например, Реестр), но является гибким и более свободным, поэтому вы можете при необходимости смоделировать эти зависимости.

0 голосов
/ 07 апреля 2010

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

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

0 голосов
/ 11 апреля 2010

Я имел дело с этим довольно много лет. Я бы сказал, что добавление производного от 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');
}
0 голосов
/ 06 апреля 2010

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

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

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

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

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

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

Некоторые цитаты для вашего развлечения:

" Глобальные переменные используются постоянно, многими, многими программистами. Теперь мы просто называем их Singletons. " - DannySmurf

" Они совершенно, фундаментально, абсолютно, невероятно, поразительно злые. " - Винко Врсалович

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

...