Pull to refresh

Comments 28

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

$user_form = $this->getServiceLocator()->get('UserForm');

Не стоит его так использовать. Используйте DI.
Чем плох сервис менеджер в данном случае?
Добавляет еще одну зависимость (себя).
Усложняет тестирование.
Делает зависимости неявными.
Ухудшает навигацию (конечно, можно обойти всякими /** var… */, но тогда засоряется код).
Очень распространенная проблема у новичков — злоупотребляют сервис менеджером.
Мы сервис менеджер используем только в Module.php, где он выполняет роль DI, а контроллеры/вьюхелперы/сервисы даже не знают о его существовании.

Тестирование, я б сказал, становится адом.
Кирилл, а вы можете привести практический пример использования DI в этом контексте? Честно говоря, дальше доки, в которой класс А зависит от класса Б я пока не продвинулся.
У вас будет вместо вызова локатора — объект формы как параметр конструктора, либо сеттера (зависит от конфигурации). И соответственно эти зависимости контролера/сервиса должны быть описаны (Zend\Di\Definition) в контексте DI (в zf из коробки есть авто связь (wire) по подсказкам типов, как вариант (RuntimeDefinition) ).
А не могли бы привести пример в виде кода? Меня даже больше интересует не сам DI — с ним более менее ясно, а тесты. Что именно тестируется и как. Давно ищу какую-нибудь толковую статью по тестированию ZF2. Интересуют тесты не самого ZF2, а бизнес логики, конечно.
Тут не особо зависит zf2 или что-то другое. Общий принцип такой:

public function test_something_should_do_something()
{
    $dependency = Mockery::mock('SomeBusinessServiceClass')
                    ->shouldReceive('someMethod')
                    ->with('someParams')
                    ->once()
                    ->getMock();

    $object_under_test = new ObjectUnderTest($dependency);
    
    $object_under_test->someSuperMethod();
}


Т.е. тестируется взаимодействие с зависимостью (при вызове someSuperMethod должен вызваться someMethod с параметрами). Так же можно делать фейковые возвраты при помощи andReturn. В примере библиотека моков — Mockery.
Это я понимаю и видел много примеров уровня «hello word». Интересно бы было посмотреть тесты из реального приложения, желательно большого и со сложной бизнес логикой. Буду рад, если сможете показать куски кода из каких-нибудь ваших проектов или дадите ссылку на статью, где это приводится.
Из реального проекта привести не могу, но могу порекомендовать книгу «Growing object-oriented software, guided by test».
Тем что это SL, а не DIС. Это ничем не лучше синглтонов.
А может и даже хуже, с синглтоном я хоть быстро найду что за «UserForm».
А что конкретно пугает? Роутинг довольно гибкий
то что на 2 маршрута ушло 40 строк
А можно я тут немного попиарюсь :)? Если вам интересен Twig под ZF2 попробуйте вот этот модуль: он очень классно покрыт тестами, и вообще просто замечательно и без всяких проблем работает (установка возможна как вручную, так и через Composer).
Я до сих пор не понимаю шаблонизаторов под php. Short tags и альтернативный синтаксис — вот тебе и шаблонизатор. Тем более Zend\View\Renderer\PhpRenderer довольно мощный, по сравнению с Zf1.

Можете пояснить, в чем преимущества использования шаблонизатора в разрезе php?

Вот плюсы, которые выделяю для себя я:
  1. я точно уверен, что верстальщик не поломает PHP-код внутри шаблона,
  2. я точно уверен что ленивый программист не перенесет часть логики в шаблон (встречал я и запросы к БД в шаблонах),
  3. по мне, код Twig-шаблонов получается более компактным и читабельным.

Да, против первых двух пунктов есть тестирование и код ревью, но мне удобнее недопустить появления этих проблем.
Твиг не использовал. Возникли вопросы:

я точно уверен, что верстальщик не поломает PHP-код внутри шаблона

что произойдет если верстальщик поломает разметку Твига?

я точно уверен что ленивый программист не перенесет часть логики в шаблон (встречал я и запросы к БД в шаблонах)

имхо, от такого программиста можно ожидать вещей пострашнее, чем запросы в шаблонах
самый большой плюс для меня — автоматическая защита от XSS. Так же в twig мне очень нравится идея наследования и переопределения блоков.
автоматическая защита от XSS

будет ли XSS в таком случае:

<script>{{variable}}</script>

?
в таком может быть. Но это, возможно, тот случай когда это желаемое поведение
зато точно не будет в таком

 <td>{{variable}}</td>
В общем, расслабляться полностью нельзя.
используется встроенный в фреймворк шаблонизатор

Что за встроенный в ZF2 шаблонизатор?
skeleton-application есть на packagist.org, поэтому можно обойтись без --repository-url=«packages.zendframework.com» при создании проекта

composer search zendframework/skeleton-application

Зря в офф. туториале не упомянули про кеширование конфигов.

В module_listener_options обязательно включите кеширование конфигов или все это чудо будет мержиться на лету :-)

'cache_dir' => 'data/cache',

'config_cache_key' => 'your_key',

'config_cache_enabled' => true
а еще генерация классмапов и темплейт мапов
Заранее прошу прощения у фанов ZF2.

Очень правильно сделали, что
первыми решил изучить Zend Framework 2
Я сейчас после Symfony 2 пытаюсь изучить Zend Framework 2 — это ужасно. Если изучая первый я восхищался как же все хорошо сделано, то с ZF2 я прикладываю всю свою силу воли. чтобы не застрелиться.

В итоге, более-менее удовлетворительное по функционалу приложение я смог создать после прочтения книги.
Я бы эту фразу выделил жирными красными буквами. Довольно сложное приложение с кучей сервисов на Symfony 2 я написал после прочтения официльного туториала. Ну и по ходу подглядывал в их же справочник и Поваренную книгу.

Кто-то мне объяснит почему Zend Framework 2 популярнее чем Symfony 2?
Sign up to leave a comment.

Articles