Zend Framework 2 - Приложения/Модули/Менеджеры обслуживания - Oh My

Question

Я только что начал изучать Zend Framework 2 как долгое время разработчиком Zend Framework 1. У меня небольшие проблемы, обволакивающие новую терминологию.

Назад в ZF1, если бы я хотел создать регистратор, который был глобальным для приложения, я бы добавил конфигурацию в файл application.ini, и bootstrap инициализировал бы его как ресурс (я надеюсь, что я говорю это правильно) , Итак, с любого из моих модулей-контроллеров я мог получить доступ к регистратору через ресурсы начальной загрузки.

Ввод ZF2. Модули - это немного другое зверь, они автономны, но я немного смущен тем, как они взаимодействуют с приложением. Мне кажется, что именно здесь запускается ServiceManager. Моя цель состоит в том, чтобы мой модуль (а не контроллер, но сам модуль), чтобы проверить, определил ли приложение логгер, и если он есть, используйте этот регистратор во всем модуле. Если приложение не определяет регистратор, я хочу, чтобы модуль определял регистратор для ведения журнала по модулю.

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

Примечание: Я прошел через Quickstart Роба Аллена (достаточно информации и единственный ресурс, который я нашел, который не имеет темной тени), и ZF2 (readthedocs), и googled tons уже. То, что я нахожу, состоит в том, что информация, как правило, очень неясна, когда дело доходит до «где» некоторые части головоломки.

Answer 1

Что вы знаете о Zend Framework 1.x - это «Ресурс приложения».

Понятие «приложения ресурса» заменяется в Zend Framework 2, так называемые "services" (интро here)

другое изменение является сами модули. В ZF1 модуль был главным образом подразделением вашего приложения, которое обрабатывало некоторые запросы. Это больше не относится к ZF2: если ваш модуль определяет службу или контроллер, этот доступ теперь доступен для всего приложения. Есть хорошее введение на некоторых differences between ZF1 and ZF2 by Gary Hockin.

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

Для вашего конкретного случая регистратора я предлагаю, чтобы ваш модуль всегда определял регистратор и потребляет его. Что можно сделать, чтобы определить регистратора условно имеет следующий вид:

class MyModule 
{ 
    public function onBootstrap($e) 
    { 
     // $e->getTarget() is the \Zend\Mvc\Application 
     $sm = $e->getTarget()->getServiceManager(); 

     if (!$sm->has('some-logger-name')) { 
      $sm->setFactory('some-logger-name', function ($sl) { 
       return new MyLogger($sl->get('some-db')); 
      }); 
     } 
    } 
} 

Вы бы тогда быть в состоянии использовать «некоторый регистратор-имя» ваш по всей вашей заявке.

Другой подход просто определить регистратора услуг и пусть другие модули или конфигурации заменить его позже:

class MyModule 
{ 
    public function getConfig() 
    { 
     return array(
      'service_manager' => array(
       'factories' => array(
        'some-logger-name' => 'My\Logger\Factory\ClassName' 
       ), 
      ), 
     ); 
    } 
} 

То же самое достигается с getServiceConfig, который является менее гибким и не может быть в кэше, но имеет более высокую приоритет над getConfig (позволяет переопределение) и позволяет также определять сервисные заводы, как закрытие:

class MyModule 
{ 
    public function getServiceConfig() 
    { 
     return array(
      'factories' => array(
       'some-logger-name' => function ($sl) { 
        return new MyLogger($sl->get('some-db')); 
       }, 
      ), 
     ); 
    } 
} 

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

Концепция с модулями и конфигурациями заключается в том, что «последний модуль выигрывает», поэтому вы можете определить услугу 'some-logger-name' либо в своем модуле, либо в любом загруженном перед ним модуле.

Эти же концепции применяются также к вашему соединению с БД.

Как вы можете видеть, переезд в службы уже дал вам определенную степень свободы.

Имейте в виду, что это не означает, что «Приложение» что-то определяет для вас: модули определяют ваши службы/конфиги/события и т. Д. Запуск приложения - это совокупность всех этих вещей вместе.

Answer 2

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

Приложить слушатель log событий в вашем Module.php:

public function onBootstrap(MvcEvent $e) 
{ 
    //setup some $logger 

    $sharedManager = $e->getApplication()->getEventManager()->getSharedManager(); 

    $sharedManager->attach('*', 'log', function($e) use ($logger) { 
     /** @var $e MvcEvent */ 
     $target = get_class($e->getTarget()); 
     $message = $e->getParam('message', 'No message provided'); 
     $priority = $e->getParam('priority', Logger::INFO); 
     $message = sprintf('%s: %s', $target, $message); 
     $logger->log($priority, $message); 
    }); 
} 

Затем запустить его из везде в приложении, например, контроллер:

$this->getEventManager()->trigger('log', $this, array(
    'priority' => \Zend\Log\Logger::INFO, 
    'message' => 'just some info to be logged' 
));