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

1. D7: проектирование и реализация нового модуля «Диск» Алексей Кирсанов Ведущий программист «1С-Битрикс»

2. Новое ядро D7 • Новая идеология разработки • отказ от устаревших моделей • современные технологии, современный php • ООП • сильное зацепление и слабая связанность • нетерпимость к ошибкам • Совместная работа старой и новой платформы. Постепенная миграция. • Новая библиотека классов • Обновленный жизненный цикл

3. Модуль «Битрикс24.Диск» • Замена файл-серверу, совместная работа с файлами • Текущий модуль Битрикс24.Диск (webdav) • Цели нового модуля Битрикс24.Диск (disk) • Повышение производительности • Интеграция в другие сущности • Повышение устойчивости работы • Качественный АПИ • Работа с большими объемами

4. Архитектура модуля D7 Бизнес-логика Компо-ненты БД ORM Действия над данными Данные Логика Интерфейс

5. Структура БД модуля «Диск» • Отдельные таблицы (не инфоблоки) • Нормализация • Быстрое дерево по шаблону «Таблица связей», относительно устойчивое к ошибкам при изменении структуры • Вынужденная денормализацияв узких местах (права на чтение)

6. ORM • CRUD + Query Object • Репозиторий – фасад (промежуточный слой) между бизнес-логикой и данными • События • Нет объектов

7. Генерирование классов ORM • Генератор ORM в разделе «Таблицы» • Редактирование классов ORM: единый базовый класс для файлов и папок

8. Архитектура модуля D7 Бизнес-логика Компо-ненты БД ORM Действия над данными Данные Логика Интерфейс

9. Шаблоны работы с данными • ActiveRecord • Плюсы: писать код легко, сохранение в одном месте • Минусы: нарушает принцип одной ответственности в SOLID, сложное изменение места хранения данных • DataMapper • Плюсы: соблюдается принцип одной ответственности SOLID, легко поменять место хранения • Минусы: усложнение кода • Unit of Work SOLID – принципы одной обязанности, открытости/закрытости, подстановки, разделения интерфейсови инверсии зависимостей

10. Парадигмы программирования • Ориентация на данные (Data Driven Design) • Главное – данные, а не связи между ними • Плюсы: скорость разработки, простота использования и внедрения • Минусы: хуже согласуется с концепциями ООП, сложнее поддержка и может привести к хаосу при росте проекта • Ориентация на бизнес-логику (Domain Driven Design - DDD) • Главное – предметная область, объекты, связи и зависимости • Плюсы: полностью ООП, мощный инструмент для развития и поддержки большого проекта • Минусы: гораздо сложнее в реализации

11. Варианты для нас: №1 • Ориентация на данные и ORM • ORM – часть бизнес-логики, стандартные CRUD для работы в рамках бизнес-логики • Плюсы: полностью стандартные CRUD, простота реализации, стандартные события • Минусы: оперируем не целями, а средствами; потенциально более длинный код;сложно удержать проект от распухания и хаоса при существенном росте.

12. Варианты для нас: №2 • Ориентация на данные, но нена ORM • ORM – репозиторий, т.е. прокси (промежуточный слой) между бизнес-логикой и данными, т.е. внутренний механизм • Плюсы: потенциально более компактный код, оперируем целями, АПИ настроен на конкретную задачу, не на много сложнее в реализации • Минусы: нет единообразия в CRUD, в событиях,разный АПИ в разных модулях (но можно ввести общие базовые принципы), сложно удержать проект от распухания и хаоса при существенном росте.

13. Варианты для нас: №3 • Ориентация на бизнес-логику • ORM – репозиторий, т.е. прокси (промежуточный слой) между бизнес-логикой и данными • Плюсы: полное ООП, потенциально проще развитие и поддержка, потенциально более компактный код, оперируем целями, АПИ настроен на конкретную задачу • Минусы: разный АПИ в разных модулях (но можно ввести общие базовые принципы), существенно сложнее в реализации

14. Варианты для нас: №4 • Смешанный вариант • Модульная система, где необходимо – бизнес-логика, в остальных местах – данные • Плюсы: просто там, где не надо сложно; мощно там, где нужна мощность • Минусы: нет единообразия в подходах к решению задачи

15. Бизнес-логика модуля «Диск» Folder FolderTable • Модуль для обкатки технологий File FileTable БД Абстрактный класс модели • ActiveRecord, в котором источниками данных являются DataManager(Table) Абстрактный класс DataManager

16. Безопасность в «Диске» • Наследуемые права, возможность отмены прав на любом уровне • Проверка прав – вне АПИ • Проблема выборки с проверкой прав • Контекст безопасности – провайдер прав • canRead, canRenameи т.п. • SqlExpression для списочных выборок

17. Компоненты • Компонент-класс, наследование • Базовые классы • Паттерн проектирования «Шаблонный метод» • Шаблон в базовом компоненте • Каждый запуск компонента – выполнение действия • Стандартные ответы • Стандартная обработка ошибок

18. Компонент: жизненный цикл • Жизненный цикл компонента • Узнать, какоедействие сейчас требуется выполнить • Подключить необходимые модули и сервисы (учитывая действие) • Подготовить параметры, проверить их корректность (учитывая действие) • Общий код компонента, который нужен перед всеми действиями (например, инициализация файлового хранилища) • Выполнение самого действия

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

20. Полученные результаты • Скорость построения снапшота (снимка файловой системы) • webdav-1.1 сек, 23 Мб памяти • диск - 0.13 сек, 3.5 Мб памяти • Успешно синхронизируется дистрибутив Битрикс с демо-данными (порядка 50000 файлов и папок) • Возможность интеграции в другие сущности • Возможность организации произвольных хранилищ с произвольными правилами доступа • Новый удобный АПИ

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