Дата последнего изменения: 16.01.2024
Цитатник веб-разработчиков. Александр Сербул: БУС это не "компоненты перетаскивать и галочки в админке тыкать", а это - хардкорная разработка модулей, доработка ядра, жесткий ORM, последние новинки PHP. |
Для программиста не важно, какой использовать framework. Framework - это просто основа, из которой бывает нередко целесообразнее собрать проект, чем писать с нуля. И Bitrix Framework здесь не исключение. Его надо понять, увидеть в целом, оценить его сложность и возможности. Но для ведущего разработчика, который выбирает модель реализации, знание системы важно, иначе трудно ожидать разумного и оправданного выбора архитектуры решения. Рассмотрим несколько вариантов архитектур, позволяющих решать определённые задачи.
Есть два варианта использования Bitrix Framework: "простой" и "сложный". Простой - обычный сайт, без магазина. Магазин - это более сложно, независимо от платформы. Если разработчик делал простые сайты, а потом начинает делать магазин, то ему, возможно, только с неделю нужно осваивать штатный функционал магазина.
Работая с Битрикс, нужно в первую очередь понимать, что можно выжать из стандартных компонентов и шаблонов, а что придётся дописывать.
Модель простого сайта и что должен предусмотреть проектировщик при реализации такого проекта.
В случае простого сайта не производится больших объёмов работ. Как правило, это: создание кастомных шаблонов компонентов, создание структуры сайта, шаблона сайта, несколько инфоблоков. Иногда создаётся кастомная форма добавления элемента инфоблоков.
Одно из главных отличий такого сайта - разделение прав доступа при создании контента с системой проверки и выпуска контента. Другое отличие - большие объёмы данных, к которым нужно обеспечить быстрый доступ и при этом гарантировать их сохранность.
Для хранения большого объёма данных рекомендуется использовать Облачное хранилище. Весь большой контент рекомендуется хранить там.
Для организации поэтапной работы над контентом рекомендуется использовать Документооборот и Бизнес процессы
Под "много данных" понимается сотни тысяч и миллионы элементов.
Такой проект "тяжёл" для административной части. Рекомендуется не использовать опцию Совместный просмотр разделов и элементов в настройках модуля Информационные блоки (и настройках самого инфоблока) и обязательно разносить инфоблоки по типам.
Обязательно для таких проектов необходимо:
В этом случае на сайте работает много сотрудников, и, как следствие этого, возникают повышенные запросы по безопасности, повышенные требования к разделению доступа.
На таком проекте практически всё делается штатными средствами, надо только понять систему уровней доступа к модулям, папкам, файлам:
Сложный проект, когда функционал выходит за стандартные возможности Bitrix Framework. Основная опасность: желание залезть в ядро Bitrix Framework и изменить его. В этом случае либо все изменения затрутся при обновлении, либо придётся отказаться от обновлений системы. Битрикс поддерживает обратную совместимость API, и любой проект может спокойно обновиться и получать новый функционал.
Кастомизируются или создаются компоненты. Создаются собственные модули с интерфейсом настройки, где хранятся общие классы, библиотеки. Определяем обработчики событий, которые могут менять поведение системы в нужную вам сторону, и пишем в техподдержку Bitrix Framework, если событий не хватает. Создаем свои страницы административного раздела.
В таких проектах ответственность лежит полностью на разработчиках, за Bitrix Framework не спрячешься, надо внимательно рассматривать вопросы производительности, безопасности, аудита.
Задача потребует нетривиального программирования. Используется модуль Веб-сервисы. Если не хватает функционала, то используя REST, SOAP, JSON, XML-RPC API, дорабатываем нужный функционал. Далее реализуете систему синхронизации.
Если данных очень много, то есть смысл создать свои таблицы в MySQL и хранить данные там.
В проектах такого уровня разработчики должны представлять себе администрирование систем. Так, при работе с веб-сервисами нужно понимать XML, TCP-IP, FTP. Как пойдут пакеты, где что пропадает. И кроме этого, в группу разработчиков надо подключать квалифицированного сисадмина как можно раньше.
Веб-кластер позволяет решать множество задач. При этом в коде вашего проекта ничего делать не нужно, это штатная функция Bitrix Framework.
При проектировании проектировщик должен рассчитать возможную нагрузку на проект и на основании этого сказать, что делать будем кластер. На этом его функции заканчиваются, всё остальное делает система. Нужно только настроить в административной части пулы ресурсов: базы, кэши, обл. хранилища.
Нужно подумать о логике восстановления на базе требований SLA. Надо понять, как сделать так, чтобы максимум 2 минуты система была недоступна. Последнее - резервное копирование. Нужен отдельный регламент.