Comments 30
Похоже, вы не пометили пост как перевод и не указали источник. А за идеи, обозначенные в статье, благодарю)
0
Надеюсь что автор просто забыл пометить пост как перевод) На всякий случай я напомню, что оригинал тут http://davidhemphill.com/blog/2016/09/06/presenters-in-laravel/
0
Мне всегда казалось, что подобную проблему решает ViewModel и DTO, но не Presenter
+2
Очень странная реализация подхода с кучей кода в контроллере.
Давайте теперь добавим отчество, вы будете каждый контроллер править добавляя 'middle_name' => $user->middle_name?
Давайте теперь добавим отчество, вы будете каждый контроллер править добавляя 'middle_name' => $user->middle_name?
+1
UFO just landed and posted this here
строго говоря, то что Вы сделали, это не паттерн Декоратор, а паттерн Заместитель (Proxy)
ну а в целом да, спасибо, думаю многим будет полезно узнать, что можно изменять/расширять поведение и так
ну а в целом да, спасибо, думаю многим будет полезно узнать, что можно изменять/расширять поведение и так
0
строго говоря, Вы не правы и презентер в статье это именно Декоратор, а не Прокси.
0
пересмотрел, согласен, всё-таки декоратор, простите мою невнимательность
0
Нет, вы были скорее правы.
Декоратор предполагает обёртывание объекта с сохранением интерфейса и предпологает обёртывание существующих методов, здесь интерфейса вообще нет, плюс добавляются новые методы. А здесь действительно прокси, так как проктирует обращение на модель, тем более магический __call выполняет функцию паблика морозова, нарушая инкапсуляцию, что недопустимо даже для презентера.
Декоратор предполагает обёртывание объекта с сохранением интерфейса и предпологает обёртывание существующих методов, здесь интерфейса вообще нет, плюс добавляются новые методы. А здесь действительно прокси, так как проктирует обращение на модель, тем более магический __call выполняет функцию паблика морозова, нарушая инкапсуляцию, что недопустимо даже для презентера.
+1
тут на самом деле смесь того и того, с уклоном больше в Декоратор
0
Вы тоже всё напутали. Именно Proxy дает доступ к внутреннему объекту с сохранением интерфейса но с например выполнением внутри дополнительной логики. А Decorator дает дополнительный функционал, т.е. имеет свой интерфейс.
т. е.
Вот это как раз Прокси
т. е.
предполагает обёртывание объекта с сохранением интерфейса и предпологает обёртывание существующих методов
Вот это как раз Прокси
0
Они оба предполагают соблюдение интерфейса, но цель разная. Прокси контролирует объект, а Декоратор предоставляет возможность _динамического_ изменения поведения.
+1
Соблюдение — да. Но как вы сами и сказали Декоратор дает дополнительное поведение.
Если кратко то вот:
Adapter предоставляет к своему объекту другой интерфейс.
Proxy предоставляет тот же интерфейс, управляя обращениями к вложенному объекту.
Decorator предоставляет расширенный интерфейс.
Если кратко то вот:
Adapter предоставляет к своему объекту другой интерфейс.
Proxy предоставляет тот же интерфейс, управляя обращениями к вложенному объекту.
Decorator предоставляет расширенный интерфейс.
0
Вот, _расширять_. Потому что наличие интерфейса согласуется с принципом лискоу. При этом слово расширять — лучше понимать как наследовать несколько интерфейсов, соблюдая принцип разделения интерфейсов.
Я сам об это споткнулся пару лет назад, пришлось ставить костыли из-за наличия __call и обратной совместимости вместо нормально интерфейса.
Я сам об это споткнулся пару лет назад, пришлось ставить костыли из-за наличия __call и обратной совместимости вместо нормально интерфейса.
+1
Ну вот так в Ларе это работает. Отойдите вы от понятий php и от конкретной реализации. Для модельки ее возвращаемые поля можно вполне считать интерфейсом. Презентер же берет и добавляет возможность взять еще какие то данные, сохраняя доступ к старым. И возвращаясь к теме ветки обсуждения это как раз Декоратор.
-2
Нет, вам следует убрать магический __call и тогда это будет презентер или viewmodel, а так это паблик морозов, который позволяет делать $object->delete() в слое представления.
+1
А типо, я до этого так сделать не мог? Уж извините это дает мне AR.
Вообще Вы что то мешаете всё в кучу. Начинался диалог с опровержения определения структурного паттерна. Давайте по пунктам.
1. То что в статье (какое бы оно ни было) это Декоратор. Он именно сохранил всё что умел предыдущий объект. И добавил то что тот не умел.
2. Нет это никакой не «паблик морозов» (хотя я вообще не уверен можно ли дискутировать про шуточный антипаттерн). Он не позволит обратиться к закрытым методам внутреннего объекта. Он им был бы если бы враппер (использовано в общем смысле) был бы наследником или того же класса что и внутренний объект.
3. В статье «презентор» не имеет отношения к MVP. Так же как и ваша попытка притянуть сюда архитектурный паттерн MVVM а точнее его часть ViewModel.
4. Стоит ли убрать магический call из конкретно таких презентеров? Да возможно стоит.
Вообще Вы что то мешаете всё в кучу. Начинался диалог с опровержения определения структурного паттерна. Давайте по пунктам.
1. То что в статье (какое бы оно ни было) это Декоратор. Он именно сохранил всё что умел предыдущий объект. И добавил то что тот не умел.
2. Нет это никакой не «паблик морозов» (хотя я вообще не уверен можно ли дискутировать про шуточный антипаттерн). Он не позволит обратиться к закрытым методам внутреннего объекта. Он им был бы если бы враппер (использовано в общем смысле) был бы наследником или того же класса что и внутренний объект.
3. В статье «презентор» не имеет отношения к MVP. Так же как и ваша попытка притянуть сюда архитектурный паттерн MVVM а точнее его часть ViewModel.
4. Стоит ли убрать магический call из конкретно таких презентеров? Да возможно стоит.
-1
Это вы смешали.
1. Нет, это декоратор, он сломал принцип лискоу, так как не сломал интерфейсы и не пройдёт тайпхинтинг.
2. Это паблик морозов, т.к. у вас model — протектид, а __call предоставляет к нему доступ как к публичному.
3. В статье недоразумение, а не паттерн, он нарушает сразу несколько солид принципов, о чём и был смысл данного обсуждения.
4. Обязательно уберите и код из контроллера тоже.
1. Нет, это декоратор, он сломал принцип лискоу, так как не сломал интерфейсы и не пройдёт тайпхинтинг.
2. Это паблик морозов, т.к. у вас model — протектид, а __call предоставляет к нему доступ как к публичному.
3. В статье недоразумение, а не паттерн, он нарушает сразу несколько солид принципов, о чём и был смысл данного обсуждения.
4. Обязательно уберите и код из контроллера тоже.
+1
AmdY в общем-то у декоратора и декорируемого один и тот же интерфейс должен быть, но расширять они его могут без проблем
0
Не понимаю зачем добавлять лишний слой абстракции для Laravel когда он сам изначально реализует данный шаблон.
Eloquent: Accessors & Mutators
А если нужно приводить что-то к JSON или массиву — этот механизм тоже имеется у Eloquent.
Eloquent: Serialization
Eloquent: Accessors & Mutators
А если нужно приводить что-то к JSON или массиву — этот механизм тоже имеется у Eloquent.
Eloquent: Serialization
0
Потому что Так как Модели в Ларе это AR то они и так часто перегружены логикой. И порой хочется чуток их разгрузить. И тут кто во что горазд) Сериализация всё же мне нравится больше через уже упомянутый fractal. А вот презенторы приятно использовать как часть view layer.
0
Модели в Ларе это AR то они и так часто перегружены логикой
Потому что у фреймворков дебильное понимание MVC. :)
Но мне говорят постоянно, что я работал только с Yii, хотя это касается всех (мейнстримовых) :)
-1
public function __call($method, $args)
{
return call_user_func_array([$this->model, $method], $args);
}
Мне тут ребята-фреймворщики рассказывали, что такое делать в самописи нельзя, типа не используем интерфейсы и все такое:
https://habrahabr.ru/company/mailru/blog/308788/
Что ж Вы такое советуете? :)
-1
Я презентеры делаю, но не так. Ваш пример я назову anemic presenter :) по сути набор хелпер-функций.
У меня обычно получается в контроллере что-то вида
return ['fooBar' => $fooBarPresenter->render($foo, $bar)]; // ну или $view...->with(...);
А вся логика представления для данного блока находится в FooBarPresenter.
Презентеры могут внутри создавать другие презентеры — как для комбинаций, так и для коллекций.
У меня обычно получается в контроллере что-то вида
return ['fooBar' => $fooBarPresenter->render($foo, $bar)]; // ну или $view...->with(...);
А вся логика представления для данного блока находится в FooBarPresenter.
Презентеры могут внутри создавать другие презентеры — как для комбинаций, так и для коллекций.
0
Sign up to leave a comment.
Шаблон Presenter в Laravel