Magento, IMHO, представляет собой систему PHP, которая построена на хорошо продуманных принципах кодирования – один из них – многоразовые шаблоны проектирования. Что касается примера системы PHP, я считаю, что ее можно считать довольно передовым и, следовательно, стоит рассматривать с архитектурной точки зрения.
Насколько я понимаю, существует множество шаблонов проектирования, доступных разработчику ООП. Увидев, что такие шаблоны используются в системе с открытым исходным кодом, такой как Magento, разработчик может просматривать примеры таких шаблонов в реальном использовании и на месте, а не в примерах, которые иногда могут быть довольно академичными и даже немного вводящими в заблуждение.
Таким образом, мне интересно, какие шаблоны, кроме тех, которые я перечислял ниже, программисты Magento использовали при разработке для Magento.
В качестве примечания я понимаю, что некоторые из этих шаблонов существуют на месте, поскольку они основаны на Zend Framework, MVC / Front Controller – это пара из них,
Очевидными являются:
Фабрика:
$product = Mage::getModel('catalog/product'); Синглтон:
$category = Mage::getSingleton('catalog/session');
Реестр:
$currentCategory = Mage::registry('current_category');
Опытный образец:
Mage:getModel('catalog/product')->getTypeInstance();
Сторона-наблюдатель:
# PHP Mage::dispatchEvent('event_name', array('key'=>$value)); # config.xml <config> <global> <events> <event_name> <observers> <unique_name> <class>Class_Name</class> <method>methodName</method> </unique_name> </observers> </event_name> </events> </global> </config>
Пул объектов:
$id = Mage::objects()->save($object); $object = Mage::objects($id);
Итератор:
Mage::getModel('catalog/product')->getCollection();
Шаблоны проектирования, найденные в Magento в деталях
Model View Controller, MVC для краткости – это шаблон проектирования, в котором разделяются бизнес-логика, представление и логика связи. Magento в значительной степени использует XML в качестве шаблонов-логики и HTML, смешанных с файлами PHP для своих представлений. Модели поддерживаются ORM от Varien. Большинство бизнес-логик происходит в моделях, тогда как контроллеры сопоставляют данные модели с представлениями.
Поскольку Magento его взгляды являются «жирными» – они часто содержат много логики – это не редкость, что представления имеют дополнительный класс PHP (система блоков), который поможет в рендеринге.
Образец переднего контроллера гарантирует, что есть одна и только одна точка входа. Все запросы исследуются, направляются на назначенный контроллер и затем обрабатываются в соответствии со спецификацией. Передний контроллер отвечает за инициализацию запросов среды и маршрутизации назначенным контроллерам.
Magento имеет только одну точку входа (index.php), которая инициализирует среду приложения (Mage :: app ()) и направляет запрос на правильный контроллер.
Как видно из названия, фабричная модель отвечает за факторизацию (создание экземпляров) классов. Он широко используется через базу кода Magento и использует систему автозагрузки в Magento. Определив псевдоним в модуле config.xml, вы даете фабрике знать, где можно найти классы.
В базовом классе Mage существуют различные методы, основанные на заводе-изготовителе, и один из них – getModel (). Он принимает псевдоним для класса и затем возвращает его экземпляр. Вместо того, чтобы включать вызовы, разбросанные по базе кода, шаблон фабрики будет создавать классы единообразным образом.
Другой способ получить экземпляр класса – вызвать Mage :: getSingleton (). Он принимает псевдоним класса и перед возвратом экземпляра проверяет внутренний реестр, был ли этот класс уже создан ранее – это приводит к общему экземпляру. Пример того, где это является обязательным, – это хранилище сеансов, которое должно делиться через базу кода, а не создавать его заново каждый раз.
Все сингллеты хранятся во внутреннем реестре: контейнер с глобальным охватом для хранения данных. Это не только для внутреннего использования. Методы Mage :: register ($ key, $ value), :: registry ($ key) и :: unregister ($ key) могут быть соответственно использованы для хранения, извлечения и удаления данных из реестра. Реестр часто используется для передачи данных между областями, когда они не могут быть переданы, в противном случае.
Там, где заводская модель (№ 3 в нашем списке) останавливается, где образец прототипа продолжается. Он определяет, что экземпляры классов могут извлекать конкретный экземпляр другого класса в зависимости от его родительского класса (прототипа). Примечательным примером является класс Mage_Catalog_Model_Product, который имеет метод getTypeInstance для извлечения определенного Mage_Catalog_Model_Product_Type с определенным подмножеством методов и свойств, не применимых ко всем продуктам.
Например, Mage_Downloadable_Model_Product_Type в конечном счете расширяет Mage_Catalog_Model_Product_Type. Если вы выполняете итерирование по заказу и хотите вызвать конкретный метод загружаемого продукта, вам сначала нужно разложить его на факторизацию с помощью метода getTypeInstance исходного продукта.
Пул пула объектов – это просто поле с объектами, поэтому им не нужно выделять и уничтожать снова и снова. Он не используется много в Magento, кроме как для тяжелых задач, где ресурсы могут скоро быть ограничены, например, импортировать продукты. Пул объектов (управляемый Varien_Object_Cache) может быть доступен с помощью Mage :: objects ().
Шаблон итератора определяет, что существует общий способ итерации по контейнеру с объектами. В Magento это обрабатывается Varien_Data_Collection, который в свою очередь использует различные запеченные PHP-классы (например, ArrayIterator) для получения большего количества OO-интерфейса для массивов. Это гарантирует, что коллекции моделей всегда будут иметь общий API для итерации, не завися от реальных моделей.
Lazy loading гарантирует, что загрузка данных задерживается до момента, когда это действительно необходимо. Это приводит к тому, что используются меньше ресурсов. Одно из ленивых нагрузочных действий Magento – это коллекции. Если вы хотите получить коллекцию продуктов с помощью Mage :: getModel ('catalogue / product') -> getCollection (), база данных будет затронута только тогда, когда вы действительно получите доступ к коллекции, например, итерации по ней или извлечение количество найденных моделей.
Шаблон локатора службы абстрагирует извлечение определенного сервиса. Это позволяет менять сервис, не нарушая ничего (поскольку он придерживается своей абстрактной основы), а также получает услугу, как считается подходящей для своей цели.
Райан иллюстрирует это с подключением к базе данных. Другим примером является метод Magento для кэширования, где Mage :: getCache () – это прокси-сервер локатора службы для хранилища кешей, поставляемого Zend или другими поставщиками.
Любой, кто знаком с разработкой Magento, наткнулся на шаблон модуля. Он в основном определяет, что разные домены сгруппированы в отдельные модули, которые функционируют независимо друг от друга и могут быть подключены к основной системе по своему усмотрению. В идеальной ситуации реализация шаблона модуля гарантирует, что каждый элемент может быть удален или заменен. Одним из главных героев шаблона модуля в PHP является менеджер пакетов Composer.
Хотя Magento в большой степени полагается на модульную архитектуру, она не модульная до костей. Некоторые функции сильно привязаны к ядру и не могут быть легко изменены. Существует также интенсивное использование супер-глобального основного класса Mage, который вводит всевозможные общесистемные зависимости, которые нелегко контролировать.
Magento – это управляемая событиями архитектура – результат реализации шаблона наблюдателя. Определяя наблюдателей (или слушателей), может быть подключен дополнительный код, который будет вызван по мере возникновения наблюдаемого события. Magento использует хранилище данных XML для определения наблюдателей. Если событие запускается с помощью Mage :: dispatchEvent ($ eventName, $ data), будет проводиться сбой хранения данных, и соответствующие обозреватели для $ event будут уволены.
Еще несколько:
Событие / слушатели :
Mage::dispatchEvent('model_load_before', $params);
И, конечно же, MVC , с представлениями, представленными комбинацией XML, PHP-классов и шаблонов PHTML.
Не забывайте о Lazy Loading, что означает, что доступ к базе данных происходит только в случае крайней необходимости. Например:
$collection_of_products = Mage::getModel('catalog/product') ->getCollection(); $collection_of_products->addFieldToFilter('sku','n2610');
Запрос базы данных не будет выполнен, пока вы не попытаетесь получить доступ к элементу в коллекции.
Я думаю, что отношения между Mage_Checkout_Model_Cart и Mage_Sales_Model_Quote являются шаблоном проектирования моста . Как определено wikipedia Bridge, это означает «отделить абстракцию от ее реализации, чтобы они могли варьироваться независимо». Таким образом, Корзина кажется абстракцией, а Цитата представляется реализацией.
Сервисный локатор
Allows overrides or renamed physical resources (eg Classes, DB tables, etc)
Mage::getModel('catalog/product') и $installer->getTable('customer/address_entity')
Ниже приведены шаблоны проектирования: 1. Управление представлением модели.
одиночка
завод
реестр
Передний контроллер.
Итератор.
Ленивая загрузка.
Наблюдатели (события)
В целом, с моей точки зрения, Magento использует собственную уникальную реализацию большинства шаблонов, поэтому не следует делать такую большую часть сравнения между ними.
Например, в прошлом я видел шаблон создания продукта Factory как класс, который обрабатывает классы группы объектов. В Magento объединенный конфигурационный файл xml хранит все пути к моделям, блокам и помощникам, чтобы впоследствии в процессе разработки разработчики указали только уникальный идентификатор для косой черты и фактического имени класса. Модели Singleton и Registry также отличаются от ожидаемых.