Как вы будете кэшировать контент в проекте MVC?

Используйте Memcached. Что-то вроде этого, где вы кешируете результаты запроса и пытаетесь извлечь из кеша перед БД.

Edit: Добавлено json_encoding данных … json_encode немного быстрее, чем стандартная сериализация PHP для массивов и может использоваться другими приложениями, обращающимися к данным

Memcached по умолчанию использует сжатие FastLZ.

// The ID of the item you're looking for (from $_GET or whatever) $id = 1; // Create a memcached instance $m = new Memcached(); $m->addServer('localhost', 11211); // Try retrieving the event from memcached $data = $m->get('event_' . $id); if ($data) { // If you found data in memcached, decode it for use in code $data = json_decode($data); } else { // If you didn't find the data in memcached, try retrieving from the DB $result = mysqli_query('SELECT * FROM events WHERE id = ' . $id); // If you found results in the DB... if ($data = mysqli_fetch_assoc($result)) { // Save them to memcached for future calls // Note: here, I'm using the optional param to expire it after 1 day $m->set('event_' . $id, json_encode($data), 86400); } } // Now you can use your data var_dump($data); 

Отредактировано для добавления комментариев в код

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

Кэш-выход:

Это должно быть реализовано в представлениях, как часть логики пользовательского интерфейса (представления должны быть экземплярами, а не только немыми шаблонами). Где-то такая же область, где представление объединяет шаблоны в ответе. Только в этом случае некоторые «шаблоны» фактически будут полностью без переменных.

Таким образом, вы можете кэшировать фрагменты HTML в контексте MVC .. но это не относится к вашему конкретному случаю использования. Это лучше подходит для ситуаций, когда взаимодействие с источником данных занимает слишком много времени. Например, когда хранилище является фактически REST API.

Загрузите данные:

Чтобы включить эту функцию, ее нужно будет выполнить в пределах уровня модели. Если быть точным: в сервисах (классах / экземплярах, которые в основном содержат взаимодействие между логикой домена и хранилища).

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

 $user = new User; $cache = new UserCacheMapper; $user->setId( 42 ); if ( ! $cache->fetch( $user ) ) { $storage = new UserSQLMapper( $pdo ); $storage->fetch( $user ); $cache->store( $user ); } // the $user object has been initialized 

_{Инициализация объектов на самом деле должна выполняться фабриками внутри службы, но это упрощенный пример}

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

Объекты могут кэшироваться с использованием Memcache (d), что наиболее полезно для многосерверных настроек. Для одного сервера вы можете хранить вещи в APC / Xcache и т. Д., Которые предлагают средства кэширования.

Я хотел бы кэшировать данные в методе dataaccess.

Я бы использовал memcached, поскольку его очень просто создать решение для кэширования, используя его http://memcached.org/

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

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

«В« Информатике »есть только две тяжелые вещи: недействительность кеша и называние вещей» Фил Карлтон

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

Есть несколько мест, которые вы можете кэшировать.

Если вы правильно используете HTTP (idempotency, etags, заголовки управления кешем и т. Д.), Вам может понадобиться разместить слой кэширования вне приложения и использовать пересылаемый кеш, такой как лак, для кэширования целых страниц. Тем не менее, очень легко получить HTTP неправильно, так что это может быть не так. Например, если у вас есть учетные записи пользователей, и один и тот же URL-адрес производит различный вывод сервера в зависимости от того, какой пользователь зарегистрирован, вы не можете использовать кеширование HTTP, потому что ваш ресурс зависит от состояния файла cookie. (То, что вы должны сделать, это поместить пользователя в url, Eg /mysite/{userid}/profile вместо /mysite/profile .) Вы все равно сможете использовать лак через его более сложные функции, но это будет сложнее ,

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

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

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