Здрасте! Наверняка многие знают, что такое CMS Битрикс, что она из себя представляет и какие «замечательные» код и архитектурные решения представляют его разработчики. В данном посте я хотел бы предложить новое видение на разработку компонентов и модулей системы.
HMVC
Прежде чем объяснять, что это за 4 буквы, напомню, что значат последние три:
Собственно 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 и не более, потому как в жизни я не видел хуже говнокода, но это Битрикс, с этим ничего не поделать.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Комментарии (40)
murzix
11.03.2016 10:56-4"Немного бреда", можно было и не писать. Поразмышляли про MVC и достаточно, зачем скатываться на навешивание ярлыков?
Битрикс хорош для многих задач. Мы на нём долго и успешно пишем внутреннюю CRM почти без использования стандартных компонентов. Весь код структурирован по модулям и компонентам. Модуль это не только прослойка между компонентами и инфоблоками. Там реально описывается вся бизнес логика (взаимодействие со всеми внешними базами, кладрами, егрюл, конвертация документов и прочее-прочее). И основной код пишется именно там, а не в компонентах.
Если вы общались только со студиями которые для ускорения пихали всю бизнес логику в код стандартных компонентов, то это говорит только о вашем личном опыте и не характеризует систему в целом.
А говнокод есть везде. Если вам не хочется переписать код, который вы писали год назад, значит вы перестали развиваться.
rpsv
11.03.2016 11:02-1- Я в данный момент работаю с битриксом, и очень часто встречаю таких персонажей, так что это не ярлыки, а грустная правда;
- Модули из коробки — не совсем бизнес логика. Точнее не все модели из коробки, это true MVC. Если вы писали сами, то вы как угодно могли писать компоненты и модули, а моя статья направлена на то, что есть изначально. Я считаю что размещение логики в компонентах — это в порядке вещей, собственно данному мнению посвящен пункт "Битрикс. HMVC"
- Откройте стандартные компоненты.
murzix
11.03.2016 11:08-5Битрикс сейчас переходит на новое ядро, соответственно стандартные компоненты также постепенно переписываются (в основном это касается магазина и всего что с ним связано).
Многие старые компоненты не трогались годами и код там устарел, но работает. Но это не повод тыкать туда пальцем и верещать про говнокод.
Стандартные компоненты это всего-лишь набор примеров того как можно решить задачу. Если они кого-то устраивают — можно пользоваться ими, но лучше написать своё.
koceg
11.03.2016 11:18+4Вот с первым вашим комментарием я согласен — на Битриксе можно писать хорошо, если делать всё самому.
А вот с этим поспорю.
- "Переходит на новое ядро" Битрикс уже несколько лет. И никогда до конца не перейдёт. Добавили какой-никакой ORM, вот и все значительные изменения. Говорили про новый порядок загрузки страницы, но его так и не внедрили, а это самое главное, что должно было произойти.
- Стандартные компоненты переписываются, чтобы поддерживать новый функционал, а код в них всё так же плох, они всё так же нерасширяемы.
murzix
11.03.2016 11:22-2Так я и не писал что битрикс хорошо осуществляет этот переход. Мягко говоря, они задолбали тянуть. Ни документации, ни внятных примеров. Только видосики и статьи от интерволги — это несерьёзно. Но больше всего смущает что это самое новое ядро еще не устаканилось и переходить на него сейчас опасно, ведь всё еще может измениться.
Я уже написал что стандартные компоненты это лишь примеры. Там по стандартам кодирования видно что писали их разные команды в разное время, нет смысла на них циклиться. В любом случае, они слишком избыточны для решения конкретных задач.
koceg
11.03.2016 11:26+1Стандартные компоненты это всего-лишь набор примеров того как можно решить задачу. Если они кого-то устраивают — можно пользоваться ими, но лучше написать своё.
Да, они именно так и позиционируются, но есть одна проблема — стандартные компоненты часто диктуют, каким должно быть ядро, а не наоборот.
Создаётся впечатление, что некоторые модули писались так: создавалась вёрстка, под неё подгонялись компоненты, а потом код из них выносили в модуль.
В итоге, ядром в отрыве от компонентов пользоваться вообще нельзя. Яркий пример тому — модули CRM и Техподдержка, у меня каждый раз волосы на голове шевелятся, когда приходится в классы ядра ходить. Особую пикантность добавляет то, что по CRM документации вообще нет.murzix
11.03.2016 11:30+1Техподдержка это вообще печаль =( Мы из-за неё вообще и вляпались в битрикс когда-то. Этот модуль не обновлялся уже лет 8 не меньше. Были там какие-то косметические изменения, но не более того.
Я в битрикс писал вопросы, планируют ли они его обновлять. Но они считают что там всё зашибись.koceg
11.03.2016 11:35+4В итоге, получается, что плюсов у Битрикса нет, кроме того, что "оно как-то работает". Мне когда с ним приходится работать, я банально не получаю удовольствия от ковыряния в этом вот всём.
Мы сделали на нём несколько довольно крупных вещей, но на каждом этапе вместо того, чтобы помогать, система вставляла палки в колёса.
Я бы резюмировал это так: Битрикс неплохая CMS, но очень плохой фреймворк, потому что задачи фреймворка он не решает.
Suntechnic
11.03.2016 15:06-1CRM мне кажется вообще вещь в себе. Там чтобы хоть что-то кастомизировать надо ведро слез наплакать. Но это еще не значит, что модули не являются/не должны являться реализацией модели. Все же модель это модуль, а не просто ИБ.
Что же до документации по CRM… Вы же видели ее код и архитектуру. Проще новую CRM с документацией написать чем документацию к этой.
pikeman
11.03.2016 14:20-2"Если вам не хочется переписать код, который вы писали год назад, значит вы перестали развиваться."
В точку!
fredrsf
11.03.2016 12:25+8Битрикс позволяет быстро развернуть рабочее решение, если действительно функционал системы покрывается стандартными средствами. Не более. Если же есть потребность что-то программировать, извините, начинает тошнить. 21 век, а там все global $APPLICATION, $USER, $DB… Да и стандартные компоненты убогое г — открываешь какой-нить sale.order.ajax и видишь простыню на 2к строк…
koceg
11.03.2016 12:38+3Напишу, за что поставил минус. Если убрать из текста неуместные в рамках статьи нападки на Битрикс и прописные истины вида "что такое MVC", то в ней останется только "прикольно было бы в Битриксе реализовать HMVC". И всё. Вы даже не попытались свою идею реализовать, чтобы проверить работает она или нет (ну или в статье об этом не написали, что равнозначно).
rpsv
11.03.2016 12:46-3Опять повторюсь — это концепт. Сырая реализация есть, но она сырая. А пример реализации я планировал в более масштабном примере выложить. Так что в скором времени ждите, а вообще данной статьей я планировал привлечь критические коментарии косательно самой архитектуры, а не холивар по поводу того что битрикс новое ядро уже несколько лет разрабатывает…
koceg
11.03.2016 12:51+3Нет архитектуры -> нет критики.
rpsv
11.03.2016 13:24-2Веселенько. А описание структуры это не архитектура? Или в вашем понимании архитектура это код? В статье расписано архитектура и по сути нет только программной части, реализации этой самой архитектуры.
koceg
11.03.2016 13:35+3То, что вы представили, на мой взгляд, не архитектура, а концепт — два абзаца и картинка. На мой взгляд, это не тянет на отдельную статью, о чём я и написал.
oWeRQ
11.03.2016 13:35У меня есть ощущение, что сами разработчики в качестве Service Layer используют class.php, а «контроллер» в component.php, иначе как объяснить недоразумение bitrix/catalog.smart.filter?
P. S. Вопрос на засыпку, кто знает как определяется класс используемый в class.php?… кто не знает см bitrix/modules/main/classes/general/component.php:__getClassForPath
Crank
11.03.2016 13:43+6Сейчас специально вот подумал чего бы такого для примера открыть. Берем шаблон catalog.bigdata.products и что мы видим? Ни чего не видим, по тому что кровь и слезы застилают глаза. Неужели кто-то в здравом уме поставит такой код в нормальный магазин?
WebMonet
11.03.2016 15:02Посоветуйте нормальных (правильных) ресурсов по разработке на битриксе.
Потому какprint_r( $arResult )
даже в официальном руководстве и курсах Специалиста — это адЪ.
Тем, кто решит отправить меня к официальной документации, советую посмотреть про CGuest — класс существует, а документация никак не соответствует функционалу.
kotomyava
11.03.2016 15:30+2Там всё не лучше той документации. Такое ощущение, что кроме отдела маркетига, никто ничего там просто не умеет.
Так что, лучше не ищите не существующих хороших ресурсов по разработке на битриксе, а используйте более продуманные инструменты.WebMonet
11.03.2016 17:15+1К сожалению, чаще всего Б достается в наследство. Убедить руководство перехать с Б на что-то более понятное — маловероятно.
Опять же, дурацкие мифы о легкой интеграции с 1С, легкой катомизации (читай «костылизации») — это все работает на продажи Б.
MetaDone
12.03.2016 08:34+1Посоветуйте нормальных (правильных) ресурсов по разработке на битриксе
http://symfony.com/ =)
это на случай если заказчик не будет доволен сборкой битрикса из коробки, по мне так кроме этих случаев его вообще не стоит использовать
Miklos
11.03.2016 16:22+2Говно ваш битрикс. Проклинаю тот день когда согласился "набросать из готовых компонентов магазинчик".
Alexufo
11.03.2016 16:31+4Самое смешное, что самому битриксу какой год начхать на критику, ровно как и всем кто делает на нем деньги — им просто по барабану, они давным давно даже не пытаются вступать в беседы так как на что это влияет?)))
Crank
13.03.2016 12:03Проблема в том, что все это теплое-ламповое комьюнити застыло где-то в начале 2000-х, и они продолжают писать модули с компонентами на императивный манер. Если качество продукта таково что купив его тебе нужно все переписать заново, то зачем оно надо? Поняв это адекватный народ переходит на другие системы. А если кто то предпочитает делать вид, что не видит как горит их собственный дом — это их проблема.
Alexufo
13.03.2016 12:19+2В каждой задаче есть смысл. В задаче битрикса — обслуживать желающих желательно во всей производственной цепи. Это самая главная и основная цель любого идеального бизнеса. Судя по их развитию, они не испытывают проблем с тем кому там что-то не нравится.
Им просто плевать про том где они застряли, какой у них код. Что у кого-то там не получается переписать. Бабло течет рекой, речи Рыжикова слаще меда.
Все рассуждатели о качестве продукта — просто лузеры, с точки зрения битрикса. Им на это вобще по барабану)) Сколько фирм по стране, сколько людей с этого имеют бабло, продукт просто уникален)) Все равно платит клиент за все в конечном итоге.
Я тоже был мягко говоря удивлен. когда просто никогда особо не копаясь в api, взял событие обновления корзины — и попал сразу на багу. Просто бац — "да, это баг, подтверждаем." Ну и что если я говном изолью им или куда то на форум хабр… плевать им что там магазин из за этого перестал работать так как он работал на старом ядре, когда эта бага не проявлялась, ну… с битриксом все ясно. Либо в секте которая кормит, либо ну… ну где же заменители битрикса...
autobusiness
11.03.2016 23:36+1Вот на злобу дня http://spartan.by/bitrix-to-wordpress/
Suntechnic
12.03.2016 01:55Не знаю за что вас минусуют (скорее всего за то что коммент на странице которая содержит слово битрикс), но по ссылке просто передергивания, субъективизм, а местами и откровенная ложь.
Pinsky
Почему нет варианта "не использовать битрикс совсем"?
Я сталкивался со случаями, когда интернет-магазин было проще написать с нуля на Yii2/Laravel, чем перепилить битрикс под задачи заказчиков.
ustasby
А как же CS-CART, перепиливается достаточно просто.
rpsv
Статья в первую очередь направлена для битриксоидов. А магазин можно поставить на чем угодно если есть готовый инструмент, а вот на счет проще с нуля поспорил бы. При работе с битриксом, есть много чего интересного и полезного, тут не поспоришь, чаще всего запросы заказчика покрываются стандартной сборкой битрикса и достаточно только настроить компоненты и сверстать шаблон. А вот когда задачи отходят от возможностей функционала стандартных компонентов, тогда возникают сложности.
koceg
Кого вы называете "битриксоидами" — пользователей или создателей?
Если первое, то я ничего конкретного в статье не увидел, что можно было бы применить на практике.
Если второе, то они всё, на самом деле, прекрасно понимают. Если посмотреть их выступления и почитать статьи, становится понятно, что это реальные профессионалы и они понимают, как должно быть. Главная проблема Битрикса — огромный технический долг, который с каждым релизом только увеличивают, вместо сокращения. А отказ от полного перехода на новое ядро, который изначально планировался, окончательно меня убедил, что из этой ямы им уже никогда не выбраться.
rpsv
Для разработчиков, я думаю нет смысла писать на хабру какие то послания создателям.
Это концепт. Рекомендация того как распределить данные между структурными частями системы. Конкретный код, возможно, будет в другой статье.
Diden05
Переход идет, и было понятно изначально, что он не будет не быстрым не простым, интернет магазин перевели на новое ядро, есть куча негатива, но это уже данность, все новое пишется сразу на новом ядре.
koceg
Денис, извините, я поленюсь искать информацию на форуме, я уже даже не помню, в каком году обещали выпустить это новое ядро, но:
"Новое ядро" выпускают уже несколько лет, делают это очень несистемно, документации по нему до сих пор нет — всё это говорит о том, что технический долг не закроют никогда, с этим просто нужно смириться и планировать работу соответственно.
SECL
Да, у нас тоже таких случаев было много. Битрикс нужно делать либо как в коробке, либо не делать вообще.
Groove
сорри, битриксоиды, не смог сдержаться, буду стараться в дальнейшем
