Стейт при работе с базами данных
Подходы работы с БД можно разделить на две группы:
• Ориентированные на состояние в памяти (ActiveRecord, Data Mapper, UoW)
• Ориентированные на действия с состоянием в БД (DAO)
Если ты ориентирован на состояние в памяти, то фактически твоё приложение имеет вид
1. Загрузил состояние сущностей
2. Выполнил необходимые операции по его изменению
3. Сохранил состояние
Такой подход позволяет тестировать логику изменения без базы данных, а так же унифицировать взаимодействие с БД, тем самым снижая сложность кода. Однако появляются и ограничения:
• Если кроме указанных операций что-то изменить напрямую в БД, то загруженный стейт перестанет соответствовать состоянию в БД. Любые операции с ним могут привести к некорректному результату. Чтобы этого не произошло, не стоит выполнять insert/update/delete запросы кроме как при сохранении состояния после изменения.
• Если одна и та же сущность доступны несколькими путями (например при отношениях многие-ко-многим, но не только), то при загрузке мы можем получить несколько её экземпляров. Изменение одного из экземпляров не будет автоматически отражено во втором и мы получим состояние противоречащее само себе. Чтобы такого избежать, рекомендуется использовать паттерн Identity Map.
• В серверном приложении несколько конкурентных запросов могут пытаться изменить одни сущности, что может привести к порче данных при сохранении. Чтобы этого избежать, можно использовать разные виды блокировок, а также следить чтобы всегда грузился полный набор связанных объектов, нужных для контроля правил.
В подходе, ориентированном на прямое изменение состояния в БД мы храним в памяти минимальный набор данных, необходимый для выполнения запросов. При правильной организации кода мы иногда можем использовать БД более эффективно за счет уменьшения количества передаваемых данных. Однако,
• Часть бизнес логики переезжает в запросы или в хранимые процедуры.
• Блокировки все ещё могут быть нужны, но часто они могут быть выставлены СУБД автоматически.
• API хранилища усложняется, появляется много очень разнообразных методов, теряется унификация
Первый подход становится наиболее актуален при наличии сложной модели данных, когда есть большое количество разных сущностей или при работе с ними требуется сложная бизнес логика. Второй подход полезен когда важнее оптимизация (например при действительно высокой нагрузке) или когда используются специфические хранилища, не позволяющие реализовать полноценное сохранение сущностей.
При этом, даже ориентируясь на работу с состоянием, может быть актуально для эффективности отдельные операции вынести в БД (в основном массовые), однако при этом нужно быть очень аккуратным.
Так же стоит отметить что паттерн DAO может быть применен для загрузки данных для отображения, когда нам не требуется выполнение бизнес логики, но нужен специфический срез разных частей БД.
Дополнительные материалы:
• https://martinfowler.com/bliki/DDD_Aggregate.html
• https://martinfowler.com/eaaCatalog/identityMap.html
Подходы работы с БД можно разделить на две группы:
• Ориентированные на состояние в памяти (ActiveRecord, Data Mapper, UoW)
• Ориентированные на действия с состоянием в БД (DAO)
Если ты ориентирован на состояние в памяти, то фактически твоё приложение имеет вид
1. Загрузил состояние сущностей
2. Выполнил необходимые операции по его изменению
3. Сохранил состояние
Такой подход позволяет тестировать логику изменения без базы данных, а так же унифицировать взаимодействие с БД, тем самым снижая сложность кода. Однако появляются и ограничения:
• Если кроме указанных операций что-то изменить напрямую в БД, то загруженный стейт перестанет соответствовать состоянию в БД. Любые операции с ним могут привести к некорректному результату. Чтобы этого не произошло, не стоит выполнять insert/update/delete запросы кроме как при сохранении состояния после изменения.
• Если одна и та же сущность доступны несколькими путями (например при отношениях многие-ко-многим, но не только), то при загрузке мы можем получить несколько её экземпляров. Изменение одного из экземпляров не будет автоматически отражено во втором и мы получим состояние противоречащее само себе. Чтобы такого избежать, рекомендуется использовать паттерн Identity Map.
• В серверном приложении несколько конкурентных запросов могут пытаться изменить одни сущности, что может привести к порче данных при сохранении. Чтобы этого избежать, можно использовать разные виды блокировок, а также следить чтобы всегда грузился полный набор связанных объектов, нужных для контроля правил.
В подходе, ориентированном на прямое изменение состояния в БД мы храним в памяти минимальный набор данных, необходимый для выполнения запросов. При правильной организации кода мы иногда можем использовать БД более эффективно за счет уменьшения количества передаваемых данных. Однако,
• Часть бизнес логики переезжает в запросы или в хранимые процедуры.
• Блокировки все ещё могут быть нужны, но часто они могут быть выставлены СУБД автоматически.
• API хранилища усложняется, появляется много очень разнообразных методов, теряется унификация
Первый подход становится наиболее актуален при наличии сложной модели данных, когда есть большое количество разных сущностей или при работе с ними требуется сложная бизнес логика. Второй подход полезен когда важнее оптимизация (например при действительно высокой нагрузке) или когда используются специфические хранилища, не позволяющие реализовать полноценное сохранение сущностей.
При этом, даже ориентируясь на работу с состоянием, может быть актуально для эффективности отдельные операции вынести в БД (в основном массовые), однако при этом нужно быть очень аккуратным.
Так же стоит отметить что паттерн DAO может быть применен для загрузки данных для отображения, когда нам не требуется выполнение бизнес логики, но нужен специфический срез разных частей БД.
Дополнительные материалы:
• https://martinfowler.com/bliki/DDD_Aggregate.html
• https://martinfowler.com/eaaCatalog/identityMap.html