D7: проектирование и реализация нового модуля «Диск»

Алексей КирсановВедущий программист

«1С-Битрикс»

Новое ядро D7

• Новая идеология разработки

• отказ от устаревших моделей

• современные технологии, современный php

• ООП

• сильное зацепление и слабая связанность

• нетерпимость к ошибкам

• Совместная работа старой и новой платформы. Постепенная миграция.

• Новая библиотека классов

• Обновленный жизненный цикл

Модуль «Битрикс24.Диск»• Замена файл-серверу, совместная работа с

файлами

• Текущий модуль Битрикс24.Диск (webdav)

• Цели нового модуля Битрикс24.Диск (disk)

• Повышение производительности

• Интеграция в другие сущности

• Повышение устойчивости работы

• Качественный АПИ

• Работа с большими объемами

Архитектура модуля D7

БД ORMБизнес-логика

Компо-ненты

ДанныеДействия

над данными

Логика Интерфейс

Структура БД модуля «Диск»

• Отдельные таблицы (не инфоблоки)

• Нормализация

• Быстрое дерево по шаблону «Таблица связей», относительно устойчивое к ошибкам при изменении структуры

• Вынужденная денормализация в узких местах (права на чтение)

ORM

• CRUD + Query Object

• Репозиторий – фасад (промежуточный слой) между бизнес-логикой и данными

• События

• Нет объектов

Генерирование классов ORM

• Генератор ORM в разделе «Таблицы»

• Редактирование классов ORM: единый базовый класс для файлов и папок

Архитектура модуля D7

БД ORMБизнес-логика

Компо-ненты

ДанныеДействия

над данными

Логика Интерфейс

Шаблоны работы с данными• ActiveRecord

• Плюсы: писать код легко, сохранение в одном месте

• Минусы: нарушает принцип одной ответственности в SOLID, сложное изменение места хранения данных

• DataMapper

• Плюсы: соблюдается принцип одной ответственности SOLID, легко поменять место хранения

• Минусы: усложнение кода

• Unit of WorkSOLID – принципы одной обязанности, открытости/закрытости, подстановки, разделения интерфейсов и инверсии зависимостей

Парадигмы программирования• Ориентация на данные (Data Driven Design)

• Главное – данные, а не связи между ними

• Плюсы: скорость разработки, простота использования и внедрения

• Минусы: хуже согласуется с концепциями ООП, сложнее поддержка и может привести к хаосу при росте проекта

• Ориентация на бизнес-логику (Domain Driven Design - DDD)

• Главное – предметная область, объекты, связи и зависимости

• Плюсы: полностью ООП, мощный инструмент для развития и поддержки большого проекта

• Минусы: гораздо сложнее в реализации

Варианты для нас: №1• Ориентация на данные и ORM

• ORM – часть бизнес-логики, стандартные CRUD для работы в рамках бизнес-логики

• Плюсы: полностью стандартные CRUD, простота реализации, стандартные события

• Минусы: оперируем не целями, а средствами; потенциально более длинный код; сложно удержать проект от распухания и хаоса при существенном росте.

Варианты для нас: №2• Ориентация на данные, но не на ORM

• ORM – репозиторий, т.е. прокси (промежуточный слой) между бизнес-логикой и данными, т.е. внутренний механизм

• Плюсы: потенциально более компактный код, оперируем целями, АПИ настроен на конкретную задачу, не на много сложнее в реализации

• Минусы: нет единообразия в CRUD, в событиях, разный АПИ в разных модулях (но можно ввести общие базовые принципы), сложно удержать проект от распухания и хаоса при существенном росте.

Варианты для нас: №3• Ориентация на бизнес-логику

• ORM – репозиторий, т.е. прокси (промежуточный слой) между бизнес-логикой и данными

• Плюсы: полное ООП, потенциально проще развитие и поддержка, потенциально более компактный код, оперируем целями, АПИ настроен на конкретную задачу

• Минусы: разный АПИ в разных модулях (но можно ввести общие базовые принципы), существенно сложнее в реализации

Варианты для нас: №4• Смешанный вариант

• Модульная система, где необходимо – бизнес-логика, в остальных местах – данные

• Плюсы: просто там, где не надо сложно; мощно там, где нужна мощность

• Минусы: нет единообразия в подходах к решению задачи

Бизнес-логика модуля «Диск»

• Модуль для обкатки технологий

Абстрактный

класс модели

File

Folder

Абстрактный класс

DataManager

БД FileTable

FolderTable

• ActiveRecord, в котором источниками данных являются DataManager (Table)

Безопасность в «Диске»

• Наследуемые права, возможность отмены прав на любом уровне

• Проверка прав – вне АПИ

• Проблема выборки с проверкой прав

• Контекст безопасности – провайдер прав

• canRead, canRename и т.п.

• SqlExpression для списочных выборок

Компоненты

• Компонент-класс, наследование

• Базовые классы

• Паттерн проектирования «Шаблонный метод»

• Шаблон в базовом компоненте

• Каждый запуск компонента – выполнение действия

• Стандартные ответы

• Стандартная обработка ошибок

Компонент: жизненный цикл

• Жизненный цикл компонента

1. Узнать, какое действие сейчас требуется выполнить

2. Подключить необходимые модули и сервисы (учитывая действие)

3. Подготовить параметры, проверить их корректность (учитывая действие)

4. Общий код компонента, который нужен перед всеми действиями (например, инициализация файлового хранилища)

5. Выполнение самого действия

Компонент: действия

• В конкретном компоненте просто определяются конкретные шаги - действия

Полученные результаты• Скорость построения снапшота (снимка

файловой системы)

• webdav - 1.1 сек, 23 Мб памяти

• диск - 0.13 сек, 3.5 Мб памяти

• Успешно синхронизируется дистрибутив Битрикс с демо-данными (порядка 50000 файлов и папок)

• Возможность интеграции в другие сущности

• Возможность организации произвольных хранилищ с произвольными правилами доступа

• Новый удобный АПИ

Спасибо за внимание! Вопросы?