09 PPTX, 1 МБ

advertisement
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
файлов и папок)
• Возможность интеграции в другие сущности
• Возможность организации произвольных
хранилищ с произвольными правилами
доступа
• Новый удобный АПИ
Спасибо за внимание!
Вопросы?
Download