Запросы к базе данных для быстрого обновления данных, часть 2
Это вторая и последняя часть серии о прямых запросах к базе данных, как следует из названия. В частности, речь идет об изменении статусов сообщений (но это относится не только к этому).
Фото Росса Финдона на Unsplash
Это еще один пост, который будет иллюстрацией того, как использовать $wpdb для быстрого обновления информации на основе метаданных.
И код, представленный в этом посте, работает, но если вы хотите сделать его более объектно-ориентированным, то можно проделать больше работы.
Однако, прежде чем перейти к самой статье, важно отметить, что когда дело доходит до объектно-ориентированного программирования, можно проделать большую работу по проектированию классов и созданию уровней абстракции.
В какой-то момент вам придется провести общеизвестную черту между тем, когда вы собираетесь использовать интерфейсы, насколько детализированными будут ваши классы с точки зрения того, что они абстрагируют, и тому подобным.
И цель этого поста — помочь обеспечить лучший объектно-ориентированный дизайн, но это не упражнение — сделать его как можно более оптимальным. Я обсуждаю такие темы в другой серии постов.
Но имейте это в виду, когда читаете код в остальной части поста.
Запросы к базе данных для быстрого обновления данных, часть 2
Учитывая, где мы остановились, у нас есть одна функция, выполняющая следующие действия:
- получить все сообщения, связанные с определенным мета-ключом,
- определить, нужно ли нам выйти раньше,
- обновить статус сообщения любых существующих сообщений.
Первое, что нужно отметить, это то, что одной функции слишком много, поэтому ее нужно разбить на несколько других функций. А поскольку оно объектно-ориентированное, нам нужно убедиться, что все, что делает функция, не обязательно основано на предыдущих шагах — именно в этом заключается процедурное программирование.
Вместо этого мы воспользуемся этой возможностью для настройки функций, чтобы они работали с любыми переданными им данными, независимо от того, как они туда попали.
Наконец, вы, как разработчик, должны определить, хотите ли вы иметь для этого один класс, несколько классов или иметь набор связанных классов, наследуемых от родительского класса.
Опять же, все зависит от того, насколько абстрактным вы хотите сделать код.
А пока, давайте двигаться вперед, разбивая вещи.
1 Возьмите идентификаторы сообщений с помощью связанного мета-ключа
Как и в первом посте, мы хотим убедиться, что получаем идентификаторы постов, связанные с определенным мета-ключом.
Чтобы сделать эту функцию максимально гибкой, мы настроим ее так:
- принять мета-ключ как строку,
- вернуть массив
Тогда функция будет выглядеть примерно так:
В первом посте мы разбили это на три шага (которые также описаны выше). Однако здесь мы можем объединить второй и третий шаг в одну функцию.
2 Обновите статус сообщения
Как я уже упоминал, одним из аспектов объектно-ориентированного программирования является обеспечение того, чтобы используемые нами функции не зависели от того, как были сгенерированы данные, которые они получают.
Вместо этого у них есть один алгоритм, который нужно запустить, чтобы сосредоточиться на данных, переданных в функцию. В этом случае мы хотим взять набор результатов, которые являются идентификаторами сообщений, и обновить их статус сообщений, чтобы он был установлен на draft.
Это означает, что функция примет массив, но ничего не вернет. Потенциально, вы могли бы отслеживать многие сообщения, которые он обновлял (или обновлял ли он вообще что-либо), но я сосредоточен только на рефакторинге кода, который у нас уже есть.
Вот что мы собираемся сделать. И первое, что нужно сделать, это убедиться, что есть фактические данные, с которыми можно работать. И если это так, то выполните итерацию по массиву списка идентификаторов сообщений и измените их статус сообщений:
Вы можете видеть, что это не сильно отличается от работы, проделанной в первом посте, но теперь вызывает несколько вопросов.
3 объектно-ориентированных соображения
При работе с таким кодом:
- Все это относится к одному классу или к разным классам?
- Должен ли быть базовый класс, и если да, то почему или почему бы и нет?
- Должна ли быть вызвана одна общедоступная функция, которая вызывает эти методы (и помечает их как частные)?
- Должны ли мы оставить функции публичными?
Для этого поста я собираюсь сделать следующее:
- Выставляйте каждую функцию как публичный метод. Это связано с тем, что если есть данные, возвращаемые первым методом, вы потенциально можете сделать с ними что-то еще.
- Держите его в одном классе. Таким образом, мы можем создать экземпляр одного класса, а затем использовать его для выполнения любой необходимой нам работы. Если бы были другие методы, мы бы использовали те же методы.
- Начните с интерфейса. Я не собираюсь утруждать себя написанием интерфейса только для того, чтобы показать интерфейс (я предполагаю, что это достаточно просто сделать, учитывая те функции, которые у нас есть прямо сейчас), но я возьму класс и покажу, как мы можем вызывать действует «извне вовнутрь».
Итак, я собираюсь начать с последней точки и работать в обратном порядке. Вот один из способов работы с кодом:
А вот как выглядит весь класс :
Вообще говоря, это будет служить тем же целям, что и первое, но более объектно-ориентированным образом.
Это не путь
Поскольку я пытался повторить несколько раз в этом посте, это не окончательный способ выполнить эту работу. Наоборот, это один из способов выполнения работы.
Вы можете перепроектировать, реорганизовать или повторно использовать это, как считаете нужным. Цель, однако, состоит в том, чтобы показать, как отделить логику, которую мы обычно рассматриваем как процедурную, во что-то, что немного меньше зависит от самой себя и оставляет место для дополнительной работы.