2016-03-31 2 views
1

В настоящее время я разрабатываю небольшой класс, который в значительной степени выиграет от решения кэширования, поскольку он делает HTTP-запрос сторонним API.Как реализовать сторонние кеши в пользовательский класс или библиотеку

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

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

Что было бы в этом случае воплощением передовой практики?

Я думал, что простой метод геттер/сеттер бы целесообразно:

$class->retrieveFromCache(function() { 
    return UserDefinedCache::get('user_defined_key'); 
}); 

$class->writeToCache(function($value) { 
    UserDefinedCache::set('user_defined_key', $value); 
}); 

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

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

$class->getCookieValue(function() { 
    return $_COOKIE['custom_name']; 
}); 

$class->setCookieValue(function($value) { 
    setcookie('custom_name', $value); 
}); 

Будет ли это хорошей реализацией? Есть ли недостатки, которые я забыл? Или есть лучшие решения?

ответ

0

I would follow the PSR-6 proposal.

Если вы хотите использовать несколько адаптеров, возможно, существует несколько способов их архивирования. У этого завода

$cacheInstance = CacheFactory::get('MyFancyCacheAdapter', ['options' => 'here']); 

Это возвращает сконфигурированный экземпляр данного адаптера. Адаптер должен реализовать PSR-6 CacheItemPoolInterface.

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

С другой стороны, я бы не стал изобретать колесо. Уже есть хорошо сделанные кешированные файлы, like this one for example. Если вам это не нравится, я думаю, вы можете найти много других.

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

Печенье не является кешем. Технически вы можете реализовать механизм кэширования и хранить данные в файле cookie, но я думаю, что это очень вводит в заблуждение, технически неверно и не следует принципу разделения проблем.

+0

Возможно, я спросил недостаточно ясно. Я бы хотел, чтобы это было просто. Например. пользователь моей библиотеки мог также использовать свою базу данных mysql в качестве кеша. Я действительно не вижу преимущества в том, чтобы заставить его или ее адаптировать интерфейс кэширования. Я также не хочу вносить свою библиотеку с зависимостями сторонних кешей. Консоль куки: они не должны использоваться в качестве кеша. Библиотеке необходимо записать некоторые данные в файл cookie конечного пользователя. Я действительно не хочу испортить проекты, в которых будет использоваться библиотека, путем добавления заголовков файлов cookie.Это поведение должно контролироваться пользователем библиотеки. –

+0

Не имеет смысла * не * реализовывать интерфейс и обеспечивать его соблюдение, если вы хотите разрешить использование разных кеш-серверов. Если вы хотите, чтобы это было просто, но не следовать каким-либо общим шаблонам, просто создайте класс для каждого кеша и просто создайте геттер и сеттер. В противном случае я не получу вашу проблему. – burzum

Смежные вопросы