Переваги шаблону сховища: чому ми повинні це розглянути
Учора я навів приклад шаблону репозиторію. Коротше кажучи, це один із тих шаблонів, який, на мою думку, повинен розуміти кожен, хто працює над проміжним програмним забезпеченням, створеним на основі WordPress.
Надаючи грунтовку на такому візерунку, може бути важко віддати належне візерунку, коли вам потрібно:
- представити це,
- пояснити, як це працює,
- покриття пільг,
- і наведіть невелику демонстрацію.
Але справжня перевага репозиторію полягає не лише в абстрагуванні рівня даних від решти програми, але й у тому, що його можна (або потрібно) легко замінити різними сховищами даних без зміни API.
Наприклад, в одному випадку вам може знадобитися отримати дані з бази даних WordPress, в інших випадках вам може знадобитися отримати щось із стороннього API або, можливо, є інше місце, з якого вам потрібно отримати дані.
Незважаючи на це, ідея шаблону репозиторію полягає в тому, що все, що стоїть за ним, не має значення, доки API, який він надає, працює для рівня програми, яка його викликає.
І оскільки ми розглянули базовий шаблон шаблону сховища, давайте розглянемо деякі переваги шаблону репозиторію та те, як ми можемо реалізувати його в контексті проектів WordPress.
Переваги шаблону сховища
Є кілька способів почати пояснювати шаблон, тому я почну з простої діаграми:
Переваги шаблону сховища включають абстракцію сховища даних
Зверніть увагу, що на зображенні вище є три основні компоненти:
- логіка домену (або бізнес-логіка), яку я позначив як «Додаток»,
- сховище,
- сховище даних,
Що стосується застосування, бізнес-правила завжди залишатимуться відносно послідовними. Принаймні повинні, чи не так?
Репозиторій – це те, що діє як засіб зв’язку між бізнес-логікою та сховищем даних.
Тепер сховищем даних може бути база даних, можливо, набір файлів (що я б не рекомендував), API для третьої сторони, список інформації, отриманої з іншої програми, і так далі.
Справа в тому, що репозиторій забезпечить чистий API, у який бізнес-логіка може писати та зчитувати (і про це трохи пізніше), не турбуючись про деталі того, куди йдуть дані або як вони повертаються.
Це робота сховища. І саме тому важливо мати послідовний API, і це те, що важливо переконатися, що він має деталі реалізації сховища даних, з яким він взаємодіє.
Про зчеплення
Окрім правильного сегментування вашої програми, шаблон репозиторію приносить користь архітектурі, оскільки він допомагає відокремити частини вашої програми.
Тобто бізнес-логіка нічого не знає про те, як і де зберігаються дані. Він просто знає, що може записати його та отримати, і він може зробити це за допомогою чистого API.
Репозиторій відповідає за передачу зазначеного сховища даних для організації серіалізації та пошуку, але має надавати послідовний API, тому на рівні даних не потрібно виконувати жодних синтаксичних дій для читання та запису інформації.
Деталі реалізації
До цього моменту я представляв репозиторій як конкретний клас.
Справа в тому, що програма, швидше за все, матиме кілька сховищ. І через це гарна ідея мати інтерфейси, які може реалізувати кожне сховище.
Таким чином ви визначаєте договір методів, які надаватиме репозиторій. І саме так ви можете переконатися, що кожне сховище підключено до належного сховища даних.
Реалізація інтерфейсу для кількох сховищ.
Отже, припустімо, вашій програмі потрібно спілкуватися з базою даних WordPress, а також стороннім API.
В ідеалі інтерфейс мав би надавати загальний набір методів, але деталі реалізації відрізнялися б залежно від репозиторія, оскільки кожен репозиторій матиме необхідні облікові дані та здатність спілкуватися зі сховищем даних.
Проте вдосконалення інтерфейсу надає шаблону його потужності. Логіці домену не потрібно турбуватися про те, як інформація зберігається або як її витягують. Він просто викликає методи, визначені в інтерфейсі, і необхідний об’єкт піклується про це.
Він просто викликає методи, визначені в інтерфейсі, і необхідний об’єкт піклується про це.
Як це буде виглядати в WordPress?
Це гарне запитання (і ні, я не вигадав його, щоб відповісти на нього самостійно 🙂), і може бути важко навести чудовий приклад, оскільки багато чого з того, що ми робимо, безпосередньо взаємодіє з базою даних WordPress.
Це не означає, що немає абстракцій, які ми можемо використовувати, наприклад, публікацій, сторінок, користувачів або будь-яких інших користувацьких типів публікацій, які ми хочемо створити.
Але WordPress надає API для більшої частини цього. Я бачу випадок, коли, скажімо, користувач із доданими додатковими полями міг би отримати користь від сховища користувачів.
Або спеціальний тип публікації з великою кількістю метаданих також може отримати вигоду від сховища, оскільки деталі будуть інкапсульовані в репозиторій.
Приклад високого рівня
Скажімо, наприклад, у вас є спеціальний тип публікації для події, і подія має назву та опис, які природно вписуються в назву публікації та її вміст.
Але потім він має метадані про своє місцезнаходження, час початку, час закінчення тощо. Це також може бути інкапсульовано репозиторієм, щоб ви могли мати об’єкт Event, передати його в репозиторій, а потім дозволити репозиторію надсилати інформацію в належне місце в базі даних.
Те саме стосується отримання інформації: він знає, де її отримати, як заповнити об’єкт Event, а потім повернути її абоненту.
Повернутися на правильний шлях
Але всі ці розмови про подію дещо не відповідають темі, тож, можливо, я продовжу говорити про це та про те, як це вписується в репозиторій у наступній публікації. Зрозуміло, коли говорити про це, є багато про що говорити.
Я б краще робив це меншими кроками
Коротше кажучи, якщо у вас є репозиторій подій, ви, швидше за все, маєте об’єкт або сутність події. І те, як це вписується в WordPress, користувацькі типи публікацій, метадані тощо, створює рівень складності, який спочатку може здатися складним, але зрештою окупається при роботі з більшою веб-програмою.