D7: проектирование и реализация нового модуля «Диск» Алексей Кирсанов Ведущий программист «1С-Битрикс» Новое ядро D7 • Новая идеология разработки • отказ от устаревших моделей • современные технологии, современный php • ООП • сильное зацепление и слабая связанность • нетерпимость к ошибкам • Совместная работа старой и новой платформы. Постепенная миграция. • Новая библиотека классов • Обновленный жизненный цикл Модуль «Битрикс24.Диск» • Замена файл-серверу, совместная работа с файлами • Текущий модуль Битрикс24.Диск (webdav) • Цели нового модуля Битрикс24.Диск (disk) • Повышение производительности • Интеграция в другие сущности • Повышение устойчивости работы • Качественный АПИ • Работа с большими объемами Архитектура модуля D7 БД ORM Бизнеслогика Компоненты Данные Действия над данными Логика Интерфейс Структура БД модуля «Диск» • Отдельные таблицы (не инфоблоки) • Нормализация • Быстрое дерево по шаблону «Таблица связей», относительно устойчивое к ошибкам при изменении структуры • Вынужденная денормализация в узких местах (права на чтение) ORM • CRUD + Query Object • Репозиторий – фасад (промежуточный слой) между бизнес-логикой и данными • События • Нет объектов Генерирование классов ORM • Генератор ORM в разделе «Таблицы» • Редактирование классов ORM: единый базовый класс для файлов и папок Архитектура модуля D7 БД ORM Бизнеслогика Компоненты Данные Действия над данными Логика Интерфейс Шаблоны работы с данными • • SOLID – принципы одной обязанности, открытости/закрытости, подстановки, разделения интерфейсов и инверсии зависимостей • ActiveRecord • Плюсы: писать код легко, сохранение в одном месте • Минусы: нарушает принцип одной ответственности в SOLID, сложное изменение места хранения данных DataMapper • Плюсы: соблюдается принцип одной ответственности SOLID, легко поменять место хранения • Минусы: усложнение кода Unit of Work Парадигмы программирования • Ориентация на данные (Data Driven Design) • Главное – данные, а не связи между ними • Плюсы: скорость разработки, простота использования и внедрения • Минусы: хуже согласуется с концепциями ООП, сложнее поддержка и может привести к хаосу при росте проекта • Ориентация на бизнес-логику (Domain Driven Design - DDD) • Главное – предметная область, объекты, связи и зависимости • Плюсы: полностью ООП, мощный инструмент для развития и поддержки большого проекта • Минусы: гораздо сложнее в реализации Варианты для нас: №1 • Ориентация на данные и ORM • ORM – часть бизнес-логики, стандартные CRUD для работы в рамках бизнеслогики • Плюсы: полностью стандартные CRUD, простота реализации, стандартные события • Минусы: оперируем не целями, а средствами; потенциально более длинный код; сложно удержать проект от распухания и хаоса при существенном росте. Варианты для нас: №2 • Ориентация на данные, но не на ORM • ORM – репозиторий, т.е. прокси (промежуточный слой) между бизнес-логикой и данными, т.е. внутренний механизм • Плюсы: потенциально более компактный код, оперируем целями, АПИ настроен на конкретную задачу, не на много сложнее в реализации • Минусы: нет единообразия в CRUD, в событиях, разный АПИ в разных модулях (но можно ввести общие базовые принципы), сложно удержать проект от распухания и хаоса при существенном росте. Варианты для нас: №3 • Ориентация на бизнес-логику • ORM – репозиторий, т.е. прокси (промежуточный слой) между бизнес-логикой и данными • Плюсы: полное ООП, потенциально проще развитие и поддержка, потенциально более компактный код, оперируем целями, АПИ настроен на конкретную задачу • Минусы: разный АПИ в разных модулях (но можно ввести общие базовые принципы), существенно сложнее в реализации Варианты для нас: №4 • Смешанный вариант • Модульная система, где необходимо – бизнес-логика, в остальных местах – данные • Плюсы: просто там, где не надо сложно; мощно там, где нужна мощность • Минусы: нет единообразия в подходах к решению задачи Бизнес-логика модуля «Диск» • Модуль для обкатки технологий Folder FolderTable File БД FileTable • ActiveRecord, в котором источниками данных являются DataManager (Table) Абстрактный класс DataManager Абстракт ный класс модели Безопасность в «Диске» • Наследуемые права, возможность отмены прав на любом уровне • Проверка прав – вне АПИ • Проблема выборки с проверкой прав • Контекст безопасности – провайдер прав • canRead, canRename и т.п. • SqlExpression для списочных выборок Компоненты • Компонент-класс, наследование • Базовые классы • Паттерн проектирования «Шаблонный метод» • Шаблон в базовом компоненте • Каждый запуск компонента – выполнение действия • Стандартные ответы • Стандартная обработка ошибок Компонент: жизненный цикл • Жизненный цикл компонента 1. Узнать, какое действие сейчас требуется выполнить 2. Подключить необходимые модули и сервисы (учитывая действие) 3. Подготовить параметры, проверить их корректность (учитывая действие) 4. Общий код компонента, который нужен перед всеми действиями (например, инициализация файлового хранилища) 5. Выполнение самого действия Компонент: действия • В конкретном компоненте просто определяются конкретные шаги - действия Полученные результаты • Скорость построения снапшота (снимка файловой системы) • webdav - 1.1 сек, 23 Мб памяти • диск - 0.13 сек, 3.5 Мб памяти • Успешно синхронизируется дистрибутив Битрикс с демо-данными (порядка 50000 файлов и папок) • Возможность интеграции в другие сущности • Возможность организации произвольных хранилищ с произвольными правилами доступа • Новый удобный АПИ Спасибо за внимание! Вопросы?