Бітрікс, HMVC і щіпка марення...



Здрастє! Напевно багато хто знає, що таке CMS Бітрікс, що вона з себе представляє і які «чудові» код та архітектурні рішення є його розробники. У цьому пості я хотів би запропонувати нове бачення на розробку компонентів і модулів системи.

HMVC

Перш ніж пояснювати, що це за 4 літери, нагадаю, що означають останні три:

image

Власне MVC — це шаблон проектування, який розділяє систему на три частини:
  • Модель — бізнес-логіка;
  • Контролер — логіка управління/взаємодії;
  • Подання — UI.
Плюси цього шаблону в тому, що якщо він гаразд реалізована, то бізнес-логіка повністю незалежна від C і V. Кому потрібні подробиці і хто з якихось причин досі не знає що це таке — вперед в google.

Начебто все добре, MVC прям майже панацея (це така річ, яка вирішує всі проблеми), але якщо система досить велика, то вона неминуче ускладнюється і як наслідок (чи причина) виникають проблеми масштабування. Тут на допомогу приходить добрий друг: H — Hierarchical.



Основна ідея даного шаблону в тому, що вся система ділитися на окремі, незалежні тріади (MVC'шки), які спілкуються між собою через контролери. Таким чином бізнес-логіка раніше ізольована від зовнішнього світу, і по суті система самовільно дробитися на дрібні частини, а це куди зручніше і простіше спагетті-залежностей, які неминуче виникнуть у великій системі.

Спілкування тріад відбувається шляхом запитів до контролерів. Можна виділити такі види запитів:
  • зовнішній запит — створення запиту до іншого сервера (божественне розподіл);
  • внутрішній запит — створення запиту до поточного сервера;
  • виклик функції — просто виклик дії контролера з коду, без додаткового запиту до сервера.

Бітрікс і його таргани

Бітрікс — це вкрай розрекламована і вкрай недружня для розробника система управління. Але насправді йдеться не про це, тому перейдемо до справи.

За заявою авторів, дана система реалізує шаблон MVC. Виглядає це наступним чином:



Емм… серйозно? Модель перебувати іншій структурній частині системи, окремо від контролера і подання. Окремо, Карл!!!

Насправді це досить вдалий хід, оскільки вся система заснована на компонентах і кожен з них може смикати будь-яку модель, будь-якого модуля, а якщо бути точним конкретну модель — инфоблоки. Але як по мені з точки зору MVC це невірно, контролери перевантажуються логікою (принаймні якщо дивитися на реалізацію стандартних компонентів).

Бітрікс. Моделі

Инфоблоки — це дуже зручне і гнучке рішення для зберігання інформації, тут не посперечаєшся і ігнорувати цей інструмент — нерозумно. Для наочності, структуру системи в загальному випадку можна зобразити так:



Дивлячись на цю картинку можна зробити висновок, що рішення відокремити модель біса чудове. Але в даному випадку багато логіки в контролерах (компонентах), а моделі (API) це всього лише domain model, і ніякої логіки не містять.

Бітрікс. Контролери

Бітрікс запевняє нас, що компоненти виконують роль контролерів, але я не погоджуся з цим.

Компоненти — це віджети: вони отримують на вхід дані і яким-небудь чином перетворюють їх.

Комплексні компоненти — це контролери (точніше фронт контролери): вони приймають на вхід запит користувача, парсят його і ініціюють запитану дію. Схематично це можна висловити так:



Бітрікс. HMVC

З поданням бітрікс про MVC ми познайомилися, тепер розглянемо варіанти спілкування контролерів (компонентів) між собою.

Як радить нам документація: спілкуватися компонентів можна або через глобальні змінні, або через події. Насправді це поради по кооперації модулів, але строго кажучи на компоненти вони теж застосовні, от тільки не зовсім підходять:
  • глобальні змінні — неявна передача даних;
  • події — взагалі мимо каси.
Так що на мій погляд оптимальним буде передача параметрів за посиланням:

<?
$APPLICATION->IncludeComponent('comp1',",[& $params]);
$APPLICATION->IncludeComponent('comp2',",[$params]);
// або якщо явно вказувати що є що
$APPLICATION->IncludeComponent('comp1',",['request' => $req, 'response' => & $res]);
$APPLICATION->IncludeComponent('comp2',",[$res]);
?>


Все прозоро і зрозуміло куди, що і коли надходить.

Начебто все, але немає. Кожен окремий компонент (не комплексний) повинен являти собою окрему тріаду MVC, а цього строго кажучи немає. На допомогу приходить service layer:



Завдяки такій структурі кожен компонент (не комплексний) має свою модель (service layer), з необхідною бізнес-логікою, яка в свою чергу звертається до API (domain model) для роботи з базою.

Трохи марення

Звичайно можна було б закінчити статтю пунктом вище, але емоції рвуться назовні тому я не можу мовчати. Мене дуже тішить той факт, що всі битриксоиды, не залежно від їх рівня професіоналізму кричать в один голос «використовуйте все з коробки, якщо в коробці немає, не використовуйте бітрікс взагалі!». Питається «Навіщо тоді маркетплейс?», ну да ладно.

Хлопців, серйозно? Ви розробники чи хто? Я розумію що бітрікс це якийсь конструктор (вгадайте чия це думка) в якому БАГАТО що є, але секундочку: багато — це . І мені невимовно сумно коли битриксоиды кажуть використовуйте стандартні модулі і на їх основі робіть щось.

Я не закликаю переписувати всі модулі і ліпити купу велосипедів (хоча маркетплейс ними рясніє). Для прокачування скілла звичайно варто написати пару своїх велосипедів, але із стандартних модулів можна взяти тільки API і не більше, бо в житті я не бачив гірше говнокода, але це Бітрікс, з цим нічого не поробиш.

Що вам простіше зробити?

/>
/>


<input type=«radio» id=«vv71831»
class=«radio js-field-data»
name=«variant[]»
value=«71831» />
написати свій компонент
<input type=«radio» id=«vv71833»
class=«radio js-field-data»
name=«variant[]»
value=«71833» />
розібратися з існуючим

Проголосувало 55 осіб. Утрималося 25 осіб.


Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.