✅ Новости WEB и WordPress, темы, плагины. Здесь мы делимся советами и лучшими решениями для веб-сайтов.

Общий пример шаблона репозитория в WordPress

34

По моему опыту, то, как мы сначала взаимодействуем с шаблоном проектирования репозитория, часто влияет на то, как мы думаем о шаблоне. (Все первые впечатления — это неизгладимые впечатления, верно?)

Цель этого поста — показать, как это можно реализовать в WordPress, особенно при написании объектно-ориентированных плагинов для чтения данных (запись данных может быть описана в другом посте), но перед этим я попытался придумать несколько непротиворечивостей между вариации узора, который я видел.

Вообще говоря, вот что я думаю, что шаблон репозитория должен делать:

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

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

А в случае с теми, кто читает этот пост, это, скорее всего, мы.

Шаблон репозитория в WordPress

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

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

При чтении этого следует помнить о двух вещах:

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

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

Предположим, что вы работаете с пользовательским типом сообщений для событий, а также работаете с метаданными сообщений и параметрами, связанными с чем-то вроде событий.

Вы можете сделать что-то вроде:

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

Вся эта информация может быть разбросана по разным местам, и способы ее извлечения могут различаться.

1 Получение имени события

Если мы работаем с пользовательским типом записи и нам нужно получить название события, то мы можем использовать идентификатор записи и одну из API-функций WordPress для этого.

<?php

/**
 * Retrieves the title of the Event, a custom post type.
 *
 * @param  int    $eventId the ID of the event post type
 * @return string          the title of the post.
 */
public function getName(int $eventId): string
{
  return get_the_title($eventId);
}

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

2 Получение места события

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

Общий пример шаблона репозитория в WordPress

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

Итак, сначала помощник :

<?php 
/**
 * A helper function for easily retrieving post meta data for a given Event.
 *
 * @param int    $id  the ID of the event
 * @param string $key the key for the post meta data for which we're retrieveing the data
 *
 * @return string the result of retrieiving the meta data
 */
private function get(int $id, string $key): string
{
    return get_post_meta($id, $key, true);
}

А затем функция, которая использует помощника для получения местоположения :

<?php
/**
 * @param  int    $eventID the ID of the event
 * @return string          the name of the event of an empty string
 */
public function getLocationName($eventId): string
{
    return $this->get($eventId, 'ymc-event-location-name');
}

Но в этих двух примерах мы по-прежнему используем существующие функции API. Как насчет случая, когда нам нужно поговорить с базой данных?

3 Получение URL-адреса отдельного сообщения

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

Общий пример шаблона репозитория в WordPress

Если нет, я рекомендую прочитать о функции prepare, а также о функции get_results.

Учитывая это, мы можем написать запрос, который будет делать следующее:

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

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

<?php

/**
 * @return string the URL to the event next to the current event.
 */
public function getNextEventUrl()
{
    global $wpdb;
    $results = $wpdb->get_results(
        $wpdb->prepare(
            "
            SELECT *
            FROM $wpdb->posts
            WHERE ID > (SELECT ID
                FROM $wpdb->posts
                WHERE ID = %d
                AND post_type = '%s'
                AND post_status = '%s'
                ORDER BY ID ASC) AND post_type = '%s'
            AND post_status = '%s'
            ORDER BY ID ASC
            LIMIT 1
        ",
            get_the_ID(),
            'ymc-events',
            'publish',
            'ymc-events',
            'publish') );

  $result = (isset($result[0]))? $result[0]: '';

  return $result;
}

А потом все это можно инкапсулировать в один класс, который будет, скажем, Event Repository (или EventRepository ).

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

Репозиторий определен

Прежде всего, имейте в виду следующее:

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

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

Источник записи: tommcfarlin.com

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