Преимущества шаблона репозитория: почему мы должны его учитывать
Вчера я давал пример по шаблону репозитория. Короче говоря, это один из тех шаблонов, который, я думаю, должен понимать любой, кто работает с промежуточным ПО, созданным поверх WordPress.
Когда вы даете грунтовку по шаблону, подобному этому, может быть сложно отдать должное шаблону, когда вам нужно:
- представить его,
- объяснить, как это работает,
- покрыть преимущества,
- и дайте небольшую демонстрацию.
Но реальное преимущество репозитория заключается не только в абстрагировании уровня данных от остального приложения, но и в том, что его можно (или нужно) легко заменять различными хранилищами данных без изменения API.
Например, в одном случае вам может понадобиться получить данные из базы данных WordPress, в других случаях вам может понадобиться получить что-то из стороннего API или, возможно, есть какое-то другое место, из которого вам нужно получить данные.
Несмотря на это, идея шаблона репозитория заключается в том, что все, что находится за ним, не имеет значения, пока предоставляемый им API работает для уровня вызывающего его приложения.
И так как мы рассмотрели пример шаблона репозитория, давайте взглянем на некоторые преимущества шаблона репозитория и на то, как мы можем реализовать его в контексте проектов WordPress.
Преимущества шаблона репозитория
Есть несколько способов начать объяснение шаблона, поэтому я начну с простой схемы:
Преимущества шаблона репозитория включают абстракцию хранилища данных
Обратите внимание, что на изображении выше есть три основных компонента:
- логика предметной области (или бизнес-логика), которую я обозначил как «приложение»,
- репозиторий,
- хранилище данных,
Что касается приложения, бизнес-правила всегда будут оставаться относительно последовательными. По крайней мере, они должны, верно?
Репозиторий — это то, что действует как средство связи между бизнес-логикой и хранилищем данных.
Теперь хранилище данных может быть базой данных, возможно, набором файлов (что я бы не рекомендовал), API для третьей стороны, списком информации, полученной из другого приложения, и так далее.
Дело в том, что репозиторий предоставляет чистый API, в который бизнес-логика может записывать и читать (и об этом чуть позже), не беспокоясь о деталях того, куда данные идут или как они возвращаются.
Это работа репозитория. И именно поэтому важно иметь согласованный API, и важно убедиться, что у него есть детали реализации хранилища данных, с которым он взаимодействует.
На муфте
Помимо того, что ваше приложение правильно сегментировано, шаблон репозитория приносит пользу архитектуре, поскольку он помогает отделить части вашего приложения.
То есть бизнес-логика ничего не знает о том, как и где хранятся данные. Он просто знает, что может написать и получить его, и он может сделать это, используя чистый API.
Репозиторий отвечает за обмен данными с указанным хранилищем данных для организации сериализации и извлечения, но должен предоставлять согласованный API, поэтому уровню данных не нужно выполнять какие-либо синтаксические упражнения для чтения и записи своей информации.
Детали реализации
До этого момента я представлял репозиторий как конкретный класс.
Дело в том, что приложение, скорее всего, будет иметь несколько репозиториев. И поэтому неплохо иметь интерфейсы, которые может реализовать каждый репозиторий.
Вот как вы определяете контракт методов, который будет предоставлять репозиторий. Именно так вы можете убедиться, что каждый репозиторий подключен к соответствующему хранилищу данных.
Реализация интерфейса для нескольких репозиториев.
Допустим, вашему приложению необходимо взаимодействовать с базой данных WordPress, а также со сторонним API.
В идеале интерфейс должен предоставлять общий набор методов, но детали реализации будут различаться в зависимости от репозитория, поскольку каждый репозиторий будет иметь необходимые учетные данные и возможность взаимодействовать с хранилищем данных.
Продвижение к интерфейсу — это то, что придает паттерну силу. Логике предметной области не нужно беспокоиться о том, как информация сохраняется или как она извлекается. Он просто вызывает методы, определенные в интерфейсе, и об этом позаботится необходимый объект.
Он просто вызывает методы, определенные в интерфейсе, и об этом позаботится необходимый объект.
Как это будет выглядеть в WordPress?
Это хороший вопрос (и нет, я придумал его не только для того, чтобы ответить на него самостоятельно 🙂), и может быть сложно привести отличный пример, потому что многое из того, что мы делаем, напрямую взаимодействует с базой данных WordPress.
Это не означает, что мы не можем использовать абстракции, такие как сообщения, страницы, пользователи или любые другие пользовательские типы сообщений, которые мы решили создать.
Но WordPress предоставляет API для большей части этого. Я вижу случай, когда, скажем, пользователь с добавленными дополнительными полями может извлечь выгоду из репозитория пользователей.
Или пользовательский тип записи с большим количеством метаданных также может выиграть от репозитория, инкапсулируя детали в репозиторий.
Пример высокого уровня
Скажем, например, у вас есть настраиваемый тип записи для события, а у события есть заголовок и описание, которые естественным образом вписываются в заголовок публикации и содержание публикации.
Но затем у него есть метаданные о его местоположении, времени начала, времени окончания и так далее. Это также может быть инкапсулировано репозиторием, чтобы вы могли получить объект Event, передать его в репозиторий, а затем позволить репозиторию отправить информацию в нужное место в базе данных.
То же самое касается извлечения информации: он знает, где ее получить, как заполнить объект Event, а затем вернуть ее вызывающей стороне.
Снова в пути
Но все эти разговоры о Событии немного уходят от темы, так что, возможно, я продолжу говорить об этом и о том, как это вписывается в репозиторий, в следующем посте. Очевидно, что, говоря об этом, можно многое охватить.
Я бы предпочел делать это небольшими шагами
Короче говоря, если у вас есть репозиторий событий, у вас, вероятно, есть объект события или сущность события. И то, как это вписывается в WordPress, настраиваемые типы сообщений, метаданные и т. д., вводит уровень сложности, который может показаться пугающим поначалу, но в конечном итоге окупается при работе с более крупным веб-приложением.