Всем привет! Появился неожиданный вопрос после того как завалил одно из собеседований. Интересно мнение профессионалов...
Начал разбираться с паттерном MVC и как он на самом деле представлен в битриксе. Мнений в сети много. В документации сказано, что данный паттерн реализован просто наилучшим образом (см. цитату Степана Овчинникова) https://dev.1c-bitrix.ru/learning/cour...ON_ID=2817. Но в реальной жизни соображения не всегда столь же радужные.
А путаница на самом деле дикая, начиная с первой же картинки той же документации. Казалось бы, почему контроллер (который является компонентом битрикса) вообще никак не взаимодействует с моделью, и почему это представление напрямую воздействует на модель? В моей голове рисовалась совсем иная картина. О том, что все данные от пользователя проходят через контроллер, отправляются в модель, возвращаются изменёнными и отображаются обратно в представление (как собственно оно и реализовано в Битриксе). Но покопавшись ещё немного, оказалось, что такая модель называется вовсе не MVC, а MVP ! https://ru.wikipedia.org/wiki/Model-Vi...-Presenter
А вот по MVC каких только стрелочек от одного блока к другому всюду ни нарисовано, и везде разные! Единой картинки нет. И всё же, если обратиться к википедии (будь она неладна), то получаем вот что: https://ru.wikipedia.org/wiki/Model-Vi...Controller - т.е. подразумевается, что после получения запроса от пользователя контроллер отправляет запрос в модель, данные изменяются, и МОДЕЛЬ НАПРЯМУЮ МЕНЯЕТ ПРЕДСТАВЛЕНИЕ! Позвольте, но это же совсем не то ,что мы имеем в битриксе! Только при Ajax бескомпозитной работе модель напрямую, без вызова компонента и без всякой инкапсуляции выдаст данные для последующего изменения представления. Но ведь это нестандарт, согласно теории битрикса!
Отсюда и вопрос. Уважаемые разработчики! Либо я (не побоюсь этого слова) балбес и ничего не понимаю в MVC, либо в битриксе реализован в основном паттерн MVP, а не MVC. И уж точно картинка из документации совершенно под него не подходит. Какие будут мнения на этот счет? (P.S. Ненормативная лексика будет нещадно баниться).
В тестах по Битриксу надо искать ответы в точности, как в учебных курсах Битрикса. И на собеседовании тоже.
Даже если в других книжках по-другому, а Битрикс понимает по-своему вы не докажете, что Битрикс неправ.
По-моему, объяснение Битрикса из учебного курса логичное, понятное, но упрощенное https://dev.1c-bitrix.ru/learning/cour...ON_ID=2817 Однако упрощение сделано сознательно, чтобы не перегружать ученика. В книге банды четырех всё разжевывается долго, непонятно, и с кучей примеров.
С - контроллер / contoller. Это точка входа блока (не путать с точкой входа в приложение, которая должна быть одна), точка в которой обычно принимается ожидаемый запрос с какими либо параметрами. В мире web разработки это обычно $request со всем его подноготным. Далее этот реквест обрабатывается / преобразовывается / исследуется и в зависимости от представляемых данных контроллер обращается к модели
M - model / модель (модель понятие широкое это не модель ORM). Модель в свою очередь принимаемые данные обрабатывает: записывает / читает из базы, запускает задачу, делает API запросы - вообщем тут лежит бизнес логика. Вообще модель это сложный объект, который может включать в себя: Модель ОРМ, репозиторий, сервисный слой, интерфейсный слой, и т.д. - то есть модель это по большей части часть приложения, которое на бекенде и крутится вообщем то. Модель возвращает данные в контроллер. Теперь контроллер с обработанными данными рендерит представление, передавая в него эти самые данные.
V - view / представление. Знать не знает ничего о контроллере, о модели и боже упаси о приложении и бекенде. Представление лишь только оперирует данными которые в него прокинули, тут нет никакой логики (вообще). Представление занимается выводом данных и только
В данном посте упоминается MVP. MVP это производная от MVC. Дело в том что как я сказал слой модели может быть очень толстым и большим, но так как в модели лежит бизнес логика, а данные перед рендернингом надо собрать существует слой
P - presenter / представитель - то есть слой который отвечает за сбор данных и подготовку их для представления.
Паттерн MVP это вообщем то я бы назвал MVPC (так как контроллер тоже нужен, но вероятно эта ответственность перекладывается на функционал фреймворка с которым работаем). Без контроллера никак не обойтись в любом случае, но в случае с битрикс контроллера попросту нет.
А еще есть MVVM, Supervising Controller. Но дело в том что они все производные, более модифицированные паттерны в которых добавлены уровни абстракций, для ещё большей изолированности приложения. Так например можно ввести Service Layer - или слой, в котjром содержится вся бизнес логика - у него есть знание о модели (если не используется слой Repositoty Layer, который предполагает, что сервисный слой знает только о слое репозитория и не знает о слое модели). Такой паттерн можно назвать например MRSVVC. Все эти слои это всё уровни изолированности и абстракции и если мы возьмём например DDD (Domen Driven Design) то этот паттерн всю логику заключает в паттерне Domain, который в свою очередь знать не знает о базах данных, об ОРМах, и вообще о чём либо кроме например слоя API
А есть ещё понятие Pipline - когда часть приложения работает как "труба", это например "посредники" - middlewares (но это отдельная история)
Итак так называемых паттернов MVC очень много но все они вытекающие друг из друга и являются производными. Здесь главное понять суть.
Проблема заключается в том что в архитектура битрикса не построена ни на одном из них. Кто то может сказать, что битрикс на столько седой, что паттерны появились потом, возражу, паттерн MVC появился в 1979 году (https://en.wikipedia.org/wiki/Trygve_Reenskaug) И любые попытки битрикса защитить свой монолит, который попросту однажды повернул не туда (но кто то может сказать, что это просто их путь) выглядят смешно и несколько нелепо. Ребята отвергают всё и пишут своё, пишут томно и грустно и главное не по стандарту. Стандарты ребята устанавливают сами.
Битрикс компоненты это не MVC. Во первых там нет контроллера, вернее он как бы есть но это получается набор параметров компонента и само ядро компонента, отсюда непонятно что такое контроллер. Явного выделения в коде нет и не будет. Контроллер плавно смешан с моделями, логика может быть как в контроллере, так и в модели, так и в шаблоне (привет result_modifier и прочие костыли кастомизации). Не ищите того, чего в битриксе нет. Шаблоны его смачно приправлены логикой и с 12 версии работа с компонентами ухудшается по причине их постоянного усложнения (не понимаю что мешает сделать компоненты с минимальным функционалом, который можно расширить). То что ребята выносят код из компонентов в "модели" делает их ещё хуже, так как кастомизировать придется и компонент и модель. В битриксе своя атмосфера, даже OAuth2.0 они умудрились сделать немного со "своими прибабахами", не ищи там полезного. Хочешь развиваться как разработчик - бери другие системы, не хочешь быть разработчиком - хочешь тупо форичи собирать и получать деньги - велком в битрикс на джуна, который не останется без куска хлеба уж точно.
Подытожим. Проблема понимания паттернов не из за того что ты "тупой", а из за того что ты эти паттерны не можешь реализовать в БУСе. Они там не к месту. Это всё равно что бомжа нарядить в царский сюртук - это можно, но не к месту. Поэтому возникает тонна вопросов "Как это? Что это? Почему это? и Зачем это?". Если ты решишь свой мозг поставить на рельсы битрикса и примешь за истину ту ужасную картинку об MVC что они нарисовали в документации, то ты просто запутаешься, потому что четких понятий у тебя нет - там всё притянуто за уши.
В дополнение к предыдущему комментарию. В Битриксе нет в принципе mvc, по крайней мере нет ни в одном стандартном компоненте человеческой реализации. Даже в документации предлагают создавать свои компоненты через задницу, в них и обработка request, и запросы к базе, и кеширование, и бывает даже html внутри класса компонента, потом ко всей этой шляпе подключается шаблон, где внутри будут такие же компоненты, делающие все сразу. Но есть одна возможность делать правильно и удобно: один компонент на страницу. Компонент строго в роле контроллера. Т.е. компонент !== Модель. А для кучи разных данных тогда нужно писать свои модели и сервисы, в компонте/контроллере вызываются эти модели и сервисы которые внутри себя делаю всю работу, и результат отдается в шаблон, и в шаблоне только вывод, никаких ещё 100500 компонентов. И тогда получается более менее нормальная реализация, практически как в любом нормальном фреймворке. P.s. да, в тех же фрейморках есть всякие виджеты, да, в Битриксе для этого можно использовать те же компоненты, но блин это нормально и как правило достаточно редко должно быть. А в типичном Битрикс проекте можно сказать везде одни виджеты, тесно связаны друг с другом и везде по 300 раз логика с выводом смешивается. P.p.s. ну и такой подход приводит к отказу от компонентов ядра, для тех кто умеет программировать это очень хорошо, для тех кто не умеет, очень не хорошо, и результат скорее всего будет хуже чем лапша коробочных компонентов.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».