Использование паттерна Proxy для организации кэширования на PHP

Если у вас в контроллере нужно часто решать — использовать кэш или нет, то давайте рассмотрим вашу задачу подробнее — мне в голову не приходит зачем это может быть нужно.

это не конкретный реальный проект, сборки из разных опытов.
Если для конкретики, например, есть CMS frontend и backend, которой используют один слой модели (коробочное решение, залил на хостинг и работает) при этом frontend должен работать через кэш, а backend с живыми данными, как в этом случае быть?

Использование паттерна Proxy для организации кэширования на PHP

кто минусует, напишите в комментариях что-нибудь по делу, всем же будет полезно.

Использование паттерна Proxy для организации кэширования на PHP

Большое спасибо за комментарий.

достаточно встроить кэш на пути к Storage для всех сущностей.

но тогда мы лишаемся возможности обратиться к живым данным минуя кэш?

Использование паттерна Proxy для организации кэширования на PHP

они схожи между собой, три шаблона: адаптер, декоратор и прокси. Общая идея — выступить контейнером для реального объекта, а дальше, адаптер — транслирует один интерфейс в другой, декоратор — добавляет новую функциональность без наследования, а прокси сохраняет интерфейс, но между вызовами делает что-то ещё, кэширует, контролирует доступ и т.д.

Использование паттерна Proxy для организации кэширования на PHP

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

Использование паттерна Proxy для организации кэширования на PHP

По факту, за счет магического метода __call() интерфейс прокси будет автоматически совпадать с реальным объектом. Но проблема может быть в том, что $news в нашем примере стал объектом другого типа, и если где-то в коде есть проверки типа (например instanceof или тип данных в параметрах метода), то эти проверки сломаются. Чтобы этого избежать надо просто наследовать \Cache\Proxy от \Storage, разумеется универсальность класса в этом случае снизится.

Применяем делегирование совместно с наследованием для организации контроллеров действий

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

Применяем делегирование совместно с наследованием для организации контроллеров действий

это да, но где тогда размещать эту логику? в модели тоже не правильно — она не должна знать ни о формах, ни о реквестах, получается отдельный класс как тут habrahabr.ru/post/213971/#comment_7362351

Применяем делегирование совместно с наследованием для организации контроллеров действий

По такому принципу?

Class Common_EditActionHelper implements Common_IActionHelper
{
       protected $controller = null;
       
       public function __construct( Zend_Controller_Action $controller ) {
           $this->controller = $controller; 
       }
     
       public function execute()  {
            // логика из _editActionHelper()
       }
}

Class Common_Controller extends Zend_Controller_Action
{
       public function executeActionHelper( $action ) {
             $class = 'Common_' . $action . 'ActionHelper'; // опустим валидацию $action для наглядности
             $helper = new $class( $this );
             $helper->execute();  
       }

}

Class VideoController extends Common_Controller 
{
       public function editAction() {
           $this->executeActionHelper( 'edit' );
       }
}

Применяем делегирование совместно с наследованием для организации контроллеров действий

а можно получить гибкость

Применяем делегирование совместно с наследованием для организации контроллеров действий

В этом случае не нужные экшены будут доступны через веб, т.е. вы добавили новый контроллер Test — смотрите в него он пустой, а на самом деле, через веб доступны и /test/edit/, /test/add/ и т.д. добавили в базовый контроллер еще одни общий экшн и он сразу появился во всех контроллерах, даже в тех, где он не нужен.

Применяем делегирование совместно с наследованием для организации контроллеров действий

это фргагменты класса, в реале есть вариант «выйти без сохранения» со снятием блокировки.

Применяем делегирование совместно с наследованием для организации контроллеров действий

принцип хороший, но не слишком ли это радикально целый класс ради одного метода?

ORM в PHP быть или не быть?

согласен

ORM в PHP быть или не быть?

Далее например строим запрос с помощью qb — потом он разбирается. Спрашивается зачем?

— если запрос может быть гибким, поиск например, по многим полям в разных комбинациях.

ORM в PHP быть или не быть?

Есть еще очень популярные варианты — как yii/laravel/kohana/phalcon/propel, — последний вариант
а еще нет варианта с велосипедом — второй вариант

ORM в PHP быть или не быть?

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

так и было собственно

ORM в PHP быть или не быть?

интересный взгляд

ORM в PHP быть или не быть?

смущает тихая ленивость, которая скрывает ошибки, этого же можно добиться используя явный метод вроде loadText()

ORM в PHP быть или не быть?

я бы так не делал ). Была такая ситуация, в select() перечислил только необходимые поля (выборка ~150 записей), через несколько дней появилась необходимость вывести в шаблоне еще одно поле, про select к этому времени успешно забыл, но оно само заработало, доктрина не ругнулась, что поля нет, а тихо сходила в базу за ним… 150 раз ) поскольку база девеловская, без нагрузки, на глаз это почти не заметно, увидел случайно в профайлере.