Объекты глобальной базы данных

Question

Я недавно начал изучать Laravel, и я заметил, что объект DB передается через use, что позволяет получить доступ к объекту в любых созданных методах. Я предполагаю, что это делается путем хранения информации о соединении с базой данных как статических свойств или ссылки на внутренние переменные.

Прямо сейчас, в моем собственном (не-Laravel) коде, у меня есть объект PDO и MySQL, созданный в файле, загруженном на каждую страницу, который я в конечном итоге импортирую в любые функции/методы через global, но я осознание этого может быть немного утомительным. Есть лучший способ сделать это? Единственное, о чем я могу думать, это создать объект со статическим свойством, являющимся массивом объектов БД, и статической функцией, которая возвращает их, поэтому я могу получить к ним доступ как DB::use('mysql')->query, а что нет.

Answer 1

То, что вы должны изучить, называется автозагрузкой. В частности, с именами наверху называется автозагрузка PSR-4. Все это генерируется композитором при использовании Laravel. Вы можете управлять композитором независимо от Laravel. Джеффри Пути, создатель Laravel, объясняет автозагрузку PSR-4 лучше, чем мог. https://laracasts.com/lessons/psr-4-autoloading

Вот документация по использованию композитора для автоматической загрузки. https://getcomposer.org/doc/01-basic-usage.md#autoloading

Answer 2

Этот laravel, используемый, называется traits. Это, в основном, сокращение на уровне препроцессора для копирования-вставки. И да, переменные, к которым относятся эти частные черты, являются статическими (также известными как «глобальное состояние»). По существу, laravel делает это так же, как вы, но с большим количеством синтаксического сахара. Это плохо.

Итак, лучший способ.

Ну, у вас есть три основных варианта:

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

• использовать услуги определения местоположения, реестр или синглтонов (которые все анти-паттерн)

• используют систему, называемую «зависимость инъекции контейнер» или DI контейнер

Теперь есть DI контейнеры доступны там, но оба варианта я призываю вас посмотреть на бы Auryn и DependencyInjection компонент Symfony в. У них обоих довольно хорошие руководства, но один из них в основном основан на отражении, а другой - на основе конфигурации.

И в документации Auryn специально рассматривается пример sharing PDO.

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

Любые последующие вопросы?