Базовий шаблон сховища
Щоразу, коли ви працюєте над великим проектом, який базується на WordPress, ймовірність того, що ви працюватимете з кількома джерелами даних, тобто базою даних WordPress, є вищою, ніж зазвичай. Наприклад, ви можете працювати над проектом, який має координувати інформацію з:
- база даних WordPress,
- система тикетів служби підтримки,
- система імпорту вмісту,
- інший сторонній API,
- і можливо більше.
І коли це станеться, писати код, який полегшить отримання інформації з цих різних місць, може стати трохи громіздким. Це те, про що зазвичай говорять розробники, коли говорять про «шари» у своїй програмі.
- є рівні для представлення інформації користувачеві,
рівні для обробки бізнес-логіки (або логіки домену), - рівні для зв’язку з API,
- і шари для зберігання даних.
Чесно кажучи, вам не обов’язково мати різноманітні сховища даних, щоб спостерігати, щоб створити рівень, який спрощує надсилання та отримання даних із бази даних, саме тоді це більш поширене. Ви можете так само ефективно працювати з одним сховищем даних, наприклад базою даних WordPress, реалізуючи шаблон репозиторію.
Незважаючи на це, якщо ви створюєте більший веб-сайт, веб-додаток або плагін, впровадження шаблону репозиторію – це те, що може принести дивіденди в обслуговуванні, ясності коду та розділенні проблем.
Але як це можна реалізувати в WordPress? Це не дуже складно, але по-перше, варто переглянути праймер сховища, перш ніж переходити до будь-якого коду.
Базовий шаблон сховища
Перш ніж розглядати реальну реалізацію в WordPress, важливо зрозуміти, що таке сховище, як воно визначено, що воно пропонує та його загальну реалізацію. Я поділюся додатковими матеріалами в кінці статті, а до того часу я викладу своє загальне бачення шаблону тут.
По-перше, реалізація цього шаблону може стати складнішою, ніж потрібно для новачків. Це не означає, що фактична закономірність не варта розуміння, але якщо ви просто хочете розмочити себе цим, я не прихильник кидати читачів у глибину. Я не думаю, що це найкращий спосіб навчання.
Замість цього варто розбити проблему, а потім перебудувати її у щось трохи елегантніше. Ось що я збираюся зробити.
Кілька слів про розв’язку
Говорячи про об’єктно-орієнтоване програмування, ми часто говоримо про ідею «роз’єднання» частин системи. Якщо ви знайомі зі зв’язком і згуртованістю, то знаєте чому.
Але якщо ні, досить сказати, що чим більше пов’язаних компонентів ваша система, тим важче їх змінити. Вони занадто багато знають один про одного. Тобто, якщо ви зміните один із аспектів системи, це, швидше за все, піде на каскад або вплине на іншу частину системи, чого ви ніколи не мали на увазі. Тоді вам доведеться витрачати набагато більше часу на виправлення всіх цих інших «точок дотику» по всій системі, які не потрібні.
Реалізація різних стратегій, як-от шаблон репозиторію, може допомогти роз’єднати частини системи. Приклад: презентаційний рівень не знає, як організовано базове сховище даних. Для цього не потрібно знати SQL. Йому не потрібно знати, що це база даних. Натомість йому просто потрібно знати, як спілкуватися з репозиторієм.
Гарно, правда?
Це означає, що ви можете замінити серверне сховище даних і, якщо ваш API надійний; ваша програма продовжуватиме працювати практично без змін. І ось що означає бути справді розлученим.
Реалізація шаблону сховища
Отже, як виглядає шаблон сховища? Як і у більшості шаблонів проектування, існує загальна форма шаблону, і це завжди корисно, але я думаю, що це також допомагає тим з нас, хто працює в WordPress, побачити, як це може працювати в контексті, знаєте, WordPress.
Отже, спочатку я хочу розібрати сам шаблон, а потім навести приклад того, як він може виглядати під час роботи з WordPress.
Загальна реалізація шаблону сховища
Реальна реалізація шаблону сховища досить проста. Насправді я ніколи не впевнений, що це так корисно, оскільки воно просто показує, як сховища даних, репозиторій та решта програми взаємодіють один з одним.
Не зрозумійте мене неправильно: я повністю за концептуальні моделі того, як все організовано. Особисто мені це допомагає думати про структуру програми під час її створення, але якщо вона надто загальна, це не дуже допоможе.
Але щоб дістатися до конкретного інструменту, ми повинні з чогось почати, чи не так? Тож я почну з найвищого можливого рівня і працюватиму вниз.
Як ви можете бачити на зображенні вище, у вас є кілька сховищ даних, усі з яких зчитуються через репозиторій, а потім програма запитує репозиторій, який, у свою чергу, отримує інформацію зі сховища даних.
Так, є варіанти кешування інформації, анулювання кешу та інші цікаві речі. Але це виходить за межі основного сховища. Тож поки що я не збираюся йти цим конкретним шляхом. Можливо, у наступній публікації (якщо вона виявиться для вас корисною).
Шаблон сховища в WordPress
Отже, з огляду на це, давайте подивимося на базову реалізацію того, як це може виглядати в стандартній установці WordPress. Тобто все, що ми маємо, це сховище даних. Ми не спілкуємося ні з чим іншим, але ми хочемо переконатися, що все, що взаємодіє з базою даних або API, обробляється репозиторієм
Це виглядало б приблизно так:
Як це може виглядати з WordPress
І це можна абстрагувати навіть далі. Можливо, є репозиторій дописів або репозиторій користувачів. Особисто я прихильник того, щоб мати репозиторій для кожного типу сутності, оскільки це допомагає містити пов’язану бізнес-логіку без створення великих класів, які знають усе (і без потреби).
Тож це може виглядати так:
Пакет репозиторіїв
Тоді давайте піднімемо це ще на один рівень і скажемо, що ви працюєте з API Twitter, ZenDesk API, WordPress User API та WordPress Post API. Тоді що? Є ще сховища.
Можливо, вони містяться у своєму просторі імен (що й має бути), можливо, вони реалізують загальний інтерфейс (для цього є підстави), але під час розробки я вважаю, що важливо чітко вказати, яке сховище ви використовуєте щоб бути максимально зрозумілим.
Тобто не використовуйте загальний і дозвольте середовищі виконання визначити це:
$support_repository = new Support_Repository();
$support_repository->get_tickets_for( 'tommcfarlin' );Натомість будьте чіткі:
$zendesk_repository = new ZenDesk_Repository();
$zendesk_repository->get_tickets_from( 'yesterday' );Це може здатися чимало. Не знаю, чи стикалися ви з цим, але є дивне відчуття в об’єктно-орієнтованому програмуванні, коли ми хочемо створити маленькі цілеспрямовані класи, але це створює багато файлів.
Отже, у вас є акуратно налаштовані файли, кожен з яких робить щось маленьке та цілеспрямоване. Не дозволяйте кількості файлів, які складають проект, створювати враження, що у вас погана архітектура.
Висновок
Це початковий шаблон шаблону сховища. Природно, є код, який супроводжується цим, але перед тим, як заглибитися в цю частину – оскільки код – це те, що легко губиться під час перекладу – я хотів переконатися, що я допоміг створити ілюстрацію для розробки концептуальної моделі того, як працює шаблон.
Звідси ми можемо почати говорити про реалізацію шаблону. Тож у наступній публікації чи кількох наступних публікаціях я зроблю саме це.
Тим часом не соромтеся залишати будь-які коментарі чи запитання щодо того, що тут описано.