Построение структуры данных и эффективное управление этими данными - одна из основных задач, которые необходимо решить для построения эффективного бизнес приложения. В этом стриме поговорим про эффективное управление данными с учетом современных требований (как всегда упор на использование Веб), попытаемся связать классические паттерны корпоративных приложений (по Фаулеру) и современный взгляд на вещи.
Классический взгляд предполагает активное использование ORM для отображения данных на структуры или объекты. При этом это отображение может идти как на бизнес-логику, так и на служебные сущности. Так как сегодня наиболее используемой архитектурой является клиент-сервер, причем на базе тонких клиентов, то отображение данных должна в обязательном порядке рассматриваться в контексте доставки данных. В этом смысле типовым является использование Data transfer objects (DTO).
В стриме по-прежнему рассматривается трехслойный монолит, но сами идеи обработки и передачи данных могут быть так же перенесены на другие архитектуры (например, луковую).
Ожидаемые преимущества от использования ORM:
- Высокий уровень абстракции, нас не интересует как хранятся данные;
- Независимость от СУБД, прозрачные миграции на другие СУБД;
- Производительность за счет внутренних механизмов оптимизации;
Жестокая реальность:
- низкая скорость работы;
- слабая автогенерация SQL (неэффективные запросы);
- сложности при смене СУБД (по факту привязка к СУБД остается);
- искаженная декомпозиция на объекты (по факту отражаем структуру БД);
- расхождение БД и требований бизнес-логики.
Идея использовать ORM в виде самостоятельного слоя, предоставляющего весь необходимый сервис в конечном итоге приводит к ORM-ориентированной архитектуре, т.е. мы не реализуем архитектуру так, чтобы было удобно нам, а стараемся "подогнать" решение под возможности ORM.
Тем не менее отображение данных в объекты необходима, если мы хотим работать в объектно ориентированной парадигме, но отображение должно быть максимально контролируемым и для этого очень хорошо подходят "облегченные" варианты реализации адаптированные под задачи веб-приложений, рассмотрим шаблоны корпоративных приложений (по Фаулеру) с учетом реализации в клиент-серверной веб архитектуре:
- Table data gateway
- Row days gateway
- Active record
- Data mapper
Основная идея сводится к передаче данных через DTO, а долгосрочное хранение и "правильный" стейт хранить в БД.
Существует два подхода к разделению БЛ между сервером и тонким клиентом:
- логика на сервере (мощный бэкенд)
- логика на клиенте (облегченный бэкенд, в том числе серверлес)
Такие шаблоны как Active record хороши для решений с мощным бэкендом, так как инкапсулируют в себя БЛ.
Идея: Объект содержит данные, которые сохраняются в БД посредством промежуточного слоя реализованного в виде DataMapper, он же делает обратное преобразование Шаблоны корпоративных приложений. М. Фаулер
Такой подход в отображения хорошо для реализации в Serverless решениях, когда передача данных осуществляется через DTO, а вся логика сосредоточена в клиенте.
При этом нас не интересует способ сохранения данных, а только факт получения DTO.
Данный подход наиболее распространен в современных корпоративных приложениях.
Идея: Пишем SQL, который извлекает данные из БД и передает нам в виде итерируемой структуры. Шаблоны корпоративных приложений. М. Фаулер
Данный подход как правило используется для отображения таблицы данных на набор данных. Но сам шаблон не исключает возможности отображать наборы данных из разных таблиц (т.е. отображение на уровне БД) с учетом требований БЛ.
Шаблон идеально подходит для быстрого прототипирования, но его проблема заключается в близком расположении данных и логики, а так же в современных приложениях приходится дублировать часть логики на сервере.
Если убрать логику с сервера, то мы приходит к шаблону DataMapper.
Идея: Пишем SQL, который извлекает данные из таблицы в БД отображает одну строку таблицы на один объект БЛ. Шаблоны корпоративных приложений. М. Фаулер
Данный подход используется для отображения единственной строки из таблицы с данными, особенность заключается в том, что структура данных таблицы и отображаемого объекта совпадают. Однако таблица может быть представлена вьюшкой в БД, что позволяет значительно усложнить возможности построения реальной структуры БД.
Возможно использовать разное представление данных в БД, шлюзе записи данных и БЛ, но тогда логика отображения сильно усложняется, что нежелательно и приводит к ошибкам.
У Фаулера предлагается использовать отдельные объекты, реализующие возможность поиска и отображения данных в виде объекта Row data gateway, но на практике мне больше нравится следующие разделение:
- Row data gateway для единичных операций (как правило это операции редактирования данных);
- Table data gateway для массовых операций;
Идея: Объект выполняет роль оболочки для строки таблицы или представления базы данных. добавляя к данным логику домена Шаблоны корпоративных приложений. М. Фаулер
Данный подход отображения используется в приложениях, которые содержат логику приложения на сервере (бэкенд), инкапсулируя данные и методы обработки данных. В MVC-фреймворках такой подход соответствует поведению модели.
На фронте возможно так же использовать идею из шаблона Active Record, но так как фронт не имеет прямой связи с БД, то такое поведение требует введения дополнительного слоя абстракции для работы с БД, по сути, это все тот же DTO.
