Учебник по шаблону репозитория
Всякий раз, когда вы работаете над более крупным проектом, основанным на WordPress, вероятность того, что вы будете работать с более чем одним источником данных, то есть с базой данных WordPress, выше, чем обычно. Например, вы можете работать над проектом, который должен координировать информацию из:
- база данных WordPress,
- система тикетов службы поддержки,
- система импорта контента,
- другой сторонний API,
- и возможно больше.
И когда это происходит, может стать немного громоздко писать код, который позволяет легко извлекать информацию из этих разных мест. Об этом обычно говорят разработчики, когда говорят о работе со «слоями» в своем приложении.
- есть слои для представления информации пользователю,
слои для обработки бизнес-логики (или доменной логики), - слои для связи с API,
- и слои для хранения данных.
Честно говоря, вам не нужно иметь множество хранилищ данных для просмотра, чтобы создать слой, который упрощает отправку и извлечение данных из базы данных, просто это более распространено. Вы можете так же эффективно работать с одним хранилищем данных, например с базой данных WordPress, при реализации шаблона репозитория.
Независимо от того, создаете ли вы более крупный веб-сайт, веб-приложение или подключаемый модуль, реализация шаблона репозитория — это то, что может принести дивиденды в обслуживании, ясности кода и разделении задач.
Но как это можно реализовать в WordPress? Это не очень сложно, но, во-первых, стоит ознакомиться с учебником по репозиторию, прежде чем переходить к какому-либо коду.
Учебник по шаблонам репозитория
Прежде чем рассматривать фактическую реализацию в WordPress, важно понять, что такое репозиторий, как он определяется, что он предлагает и его общая реализация. В конце статьи я поделюсь дополнительным чтением, а до тех пор я расскажу о моем общем взгляде на шаблон здесь.
Во-первых, реализация этого паттерна может оказаться для новичков более сложной, чем необходимо. Это не значит, что фактическую закономерность не стоит понимать, но если вы просто хотите разобраться с этим, я не сторонник бросать читателей в глубокий конец. Я не думаю, что это лучший способ учиться.
Вместо этого стоит разбить проблему, а затем перестроить ее в нечто более элегантное. Вот к чему я собираюсь стремиться.
Несколько слов о развязке
Говоря об объектно-ориентированном программировании, мы часто говорим об идее «разделения» частей системы. Если вы знакомы со сцеплением и сцеплением, то знаете, почему.
Но если нет, то достаточно сказать, что чем более взаимосвязаны компоненты вашей системы, тем труднее их изменить. Они слишком много знают друг о друге. То есть, если вы измените один из аспектов системы, это, скорее всего, приведет к каскаду или повлияет на другую часть системы, чего вы не ожидали. Тогда вам придется тратить гораздо больше времени на исправление всех этих других «точек соприкосновения» по всей системе, которые не должны быть необходимы.
Реализация различных стратегий, таких как шаблон репозитория, может помочь отделить части системы. Показательный пример: уровень представления не знает, как организовано базовое хранилище данных. Для этого не нужно знать SQL. Ему не нужно знать, что это база данных. Вместо этого ему просто нужно знать, как общаться с репозиторием.
Красиво, верно?
Это означает, что вы можете заменить внутреннее хранилище данных и, при условии, что ваш API надежный; ваше приложение будет продолжать функционировать практически без изменений. Вот что значит быть по-настоящему развязанным.
Реализация шаблона репозитория
Так как же выглядит шаблон репозитория? Как и в случае с большинством шаблонов проектирования, существует общая форма шаблона, и это всегда полезно, но я думаю, что это также помогает тем из нас, кто работает с WordPress, увидеть, как это может работать в контексте, знаете ли, WordPress.
Итак, сначала я хочу разобрать сам шаблон, а затем привести пример того, как он может выглядеть при работе с WordPress.
Общая реализация шаблона репозитория
Фактическая реализация шаблона репозитория довольно проста. На самом деле, я никогда не был уверен, насколько это полезно, потому что он просто показывает, как хранилища данных, репозиторий и остальная часть приложения взаимодействуют друг с другом.
Не поймите меня неправильно: я полностью за концептуальные модели организации вещей. Лично мне это помогает думать о структуре приложения при его создании, но если оно слишком общее, это не очень помогает.
Но чтобы перейти к конкретному орудию, мы должны с чего-то начать, верно? Так что я начну с максимально возможного уровня и буду двигаться вниз.
Как вы можете видеть на изображении выше, у вас есть несколько хранилищ данных, все из которых считываются через репозиторий, а затем приложение запрашивает репозиторий, который, в свою очередь, извлекает информацию из хранилища данных.
Да, есть варианты кеширования информации, аннулирование кеша и все такое забавное. Но это выходит за рамки первичного репозитория. Так что пока я не собираюсь идти по этому пути. Возможно, в будущем посте (если этот окажется вам полезным).
Шаблон репозитория в WordPress
Итак, с учетом сказанного, давайте посмотрим на базовую реализацию того, как это может выглядеть в стандартной установке WordPress. То есть все, что у нас есть, это хранилище данных. Мы не взаимодействуем ни с чем другим, но мы хотим убедиться, что все, что взаимодействует с базой данных или API, обрабатывается репозиторием.
Это будет выглядеть примерно так:
Как это может выглядеть с WordPress
И это можно абстрагировать еще дальше. Возможно, есть репозиторий сообщений или репозиторий пользователей. Лично я сторонник наличия репозитория для каждого типа сущностей, потому что это помогает содержать связанную бизнес-логику без создания этих больших классов, которые знают все (и это излишне).
Итак, это может выглядеть так:
Пакет репозиториев
Тогда давайте поднимемся еще на один уровень и скажем, что вы работаете с API Twitter, ZenDesk API, пользовательским API WordPress и API WordPress Post. Тогда что? Есть еще репозитории.
Возможно, они содержатся в своем пространстве имен (которым они должны быть), возможно, они реализуют общий интерфейс (для чего есть основания для этого), но во время разработки, я думаю, важно явно указать, какой репозиторий вы используете чтобы было максимально понятно.
То есть не используйте дженерик и дайте времени выполнения понять это:
$support_repository = new Support_Repository();
$support_repository->get_tickets_for( 'tommcfarlin' );Вместо этого будьте явными:
$zendesk_repository = new ZenDesk_Repository();
$zendesk_repository->get_tickets_from( 'yesterday' );Это может показаться много. Я не знаю, сталкивались ли вы с этим, но в объектно-ориентированном программировании возникает странное чувство, когда мы хотим создавать маленькие, сфокусированные классы, но при этом создается много файлов.
Итак, у вас есть эти аккуратно настроенные файлы, каждый из которых делает что-то маленькое и целеустремленное. Не позволяйте количеству файлов, из которых состоит проект, создать впечатление, что у вас плохая архитектура.
Вывод
Это основа шаблона репозитория. Естественно, есть код, который соответствует этому, но прежде чем погрузиться в эту часть — потому что в коде вещи легко теряются при переводе — я хотел убедиться, что помог предоставить иллюстрацию для разработки концептуальной модели того, как работает шаблон.
Отсюда мы можем начать говорить о реализации шаблона. Так что в следующем посте или в следующих нескольких постах я сделаю именно это.
А пока не стесняйтесь оставлять любые комментарии или вопросы о том, что здесь обсуждалось.