Есть ли что-нибудь плохое в шаблоне дизайна реестра?

Question

Является ли шаблон проектирования реестра хорошим решением для этого в PHP?

Для сайта социальной сети (Facebook, MySpace).

скажем, у меня есть класс Database, который создает одно соединение с БД и позволяет мне выполнять работу с БД, и класс Sessions, который позволяет мне обрабатывать сеансы, а также класс Cache, который позволяет мне кэшировать элементы и получать их. Итак, это 3 основных класса, к которым мне нужно будет иметь доступ на каждой странице моего сайта. После рассмотрения шаблона реестра за последний час, я думаю, что это идеальное решение, может быть. Я могу сохранить свои объекты базы данных, сеанса и кэша в объекте реестра, а затем добавить объект реестра на каждую страницу или в любой другой класс и получить доступ к моей базе данных, сеансам и кэш-памяти.

До этого я использовал шаблон синглтона, поэтому мне пришлось бы вызывать мой метод синглтона для всех 3 моих классов MAIN внутри каждой страницы или другого класса.

Так что мне просто интересно, есть ли какие-либо недостатки в использовании класса Registry? 1, что я могу видеть, кажется, что может быть труднее увидеть, какие классы зависят от каких других классов и тому подобное. Кроме того, что это кажется отличным решением для этого, я также увидел здесь еще один пост о классе реестра пользователя, где они хранят настройки в реестре, имеющие доступ к ним во всех других классах, в которые передается объект реестра, Я уверен, что я найду хорошее применение и для этой функции.

Так что единственный вопрос здесь - я что-то упустил или я просто разогрел лото?

---

ОБНОВЛЕНИЕ

Также, если я использую реестр для хранения объектов, я должен сделать что-то вроде этого ...

$this->session = $registry->getObject('session');

или это вместо

$this->registry->session = $registry->getObject('session');

Второй метод выглядит так, как будто бы легче понять, откуда появился этот объект?

Answer 1

Вы имеете в виду реестр Singleton с, верно? Если это так, то похоже, что все, что вам действительно нужно, - это доступ к трем глобальным объектам повсюду, но внутри другого объекта.

Итак, если вы написали cache.php, sessions.php и database.php, которые определяют классы Cache, Sessions и Database, вы хотите разместить их все внутри определенного объекта Registry в registry.php.

Прежде всего, это здорово контролировать ПОРЯДОК создания экземпляров таким образом. Это лучше, чем просто делать require_once из cache.php, sessions.php и database.php, и внутри них вы определяете не только класс, но и единственный его глобальный экземпляр. Это контролирует ПОРЯДОК создания экземпляра тем, как вы его включаете / требуете. Вид неряшливый. Лучше иметь объект Registry, чтобы, когда он был создан и стал глобальным $registry, первым делом он контролировал создание глобальных объектов в том порядке и порядке, в котором вы хотите.

Во-вторых, замечательно иметь один Registry.php с одним глобальным $ Registry. Определение глобальных переменных в разных файлах становится сложным для управления.

Теперь, когда я согласился с вами, я задаю вам важный вопрос. Как вы видите, что они разные:

$registry->getObject('session');
$registry->getObject('database');
$registry->getObject('cache');

против

$registry->getSession ();
$registry->getDatabase ();
$registry->getCache ();

Лично мне нравится последнее. Вы не используете строку «сессия» для ссылки на объект Session, полученный через супер-универсальный getObject. Вместо этого вы используете getSession() для получения сеанса. Читается лучше.

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