SQL, соединения и слои абстракции
При написании приложения, работающего с БД без использования ORM возникают вопросы о его структурировании и жизненном цикле объектов БД.
Если не рассматривать другие сущности, то условно такое приложение можно поделить на следующие слои (да простит меня Дядюшка Боб):
* Адаптеры для базы данных
* Бизнес-логика
* Контроллеры и представления
* Интеграционный слой
Рассмотрим чуть подробнее:
Адаптеры для базы данных
Это классы или функции, скрывающие в себе детали построения запросов в базу данных. Именно тут пишется SQL код, происходит разбор данных, полученных из курсора в понятные остальному коду классы.
Зачастую удобно сделать класс, который будет содержать текущее соединение с БД в своем поле и методы, делающие внутри один или несколько SQL-запросов, имеющих смысл с точки зрения основной логики программы. Этот код НЕ должен сам создавать соединение, воспользуйтесь Dependency Injection. Он так же не должен управлять транзакциями. Благодаря этому можно в дальнейшем комбинировать вызовы его методов. Также стоит избегать использования в интерфейсе этого класса слишком абстрактных методов, чтобы не переносить детали работы с БД в слой бизнес-логики.
Бизнес-логика
Этот слой содержит код обработки конкретных сценариев использования программы (use cases), то есть основную логику программы. Она абстрагирована от деталей работы базы данных или представления данных для пользователя. Для работы с базой данных она обращается к соответствующим адаптерам. Именно бизнес-логика знает о том, какие операции с базой данных являются неделимыми и управляет транзакциями.
Бизнес-логика не знает о том, откуда взялся адаптер БД, а просто использует его.
Контроллеры и представления
По сути это адаптеры, связывающие ваше приложение с его пользователями. Это могут быть view-функции веб-фреймворка, хэндлеры в телеграм боте, задачи celery, cron джобы и т.п.
Они реагируют на возникающие в вашем фреймворке события и вызывают бизнес-логику для его обработки. Контроллеры обрабатывают входящие данные, трансформируют их в понятные бизнес-логике структуры, а представления делают обратные преобразования.
Так как обрабатываемые события имеют понятный жизненный цикл, а также потому что мы технически не можем конкурентно использовать одно соединение БД, именно тут мы можем создавать наши соединения. Однако, так как настройка соединения выходит за рамки задачи контроллера, он должен создавать его не сам, а с помощью какой-то фабрики, получаемой из интеграционного слоя.
Если же фреймворк предоставляет механизм middleware, то такой объект также имеет представление о жизненном цикле события и может создавать соединение и передавать в контроллеры нужные объекты. Зачастую именно такой подход удобнее.
Интеграционный слой
Задача этого слоя собрать наше приложение из вышеописанных частей. Здесь может быть чтение конфигурации, создание экземпляров основных классов, связь их друг с другом, внедрение зависимостей и т.п.
Сюда можно так же отнести некоторые мидлвари, которые мы используем только для создания и внедрения зависимостей, привязанных к жизненному циклу обрабатываемых событий.
Итого:
1. Адаптер БД реализует единичные действия с базой и скрывает SQL код
2. Бизнес-логика оперирует транзакциями и вызывает методы адаптеров
3. Контроллер вызывает один или несколько use case в рамках соединения которое он получил сам или из мидлвари.
В начале обработки чего-либо (веб-запроса, сообщения в телеге и т.п.) достаем соединение, в конце обработки - возвращаем туда, откуда достали.
Также стоит отметить, что соединение с БД не обязательно физически открывать каждый раз, стоит использовать пулы соединений для ускорения.
Дополнительные материалы:
* https://ru.wikipedia.org/wiki/Адаптер_(шаблон_проектирования)
* https://martinfowler.com/eaaCatalog/repository.html
* https://www.ozon.ru/product/144499396/
При написании приложения, работающего с БД без использования ORM возникают вопросы о его структурировании и жизненном цикле объектов БД.
Если не рассматривать другие сущности, то условно такое приложение можно поделить на следующие слои (да простит меня Дядюшка Боб):
* Адаптеры для базы данных
* Бизнес-логика
* Контроллеры и представления
* Интеграционный слой
Рассмотрим чуть подробнее:
Адаптеры для базы данных
Это классы или функции, скрывающие в себе детали построения запросов в базу данных. Именно тут пишется SQL код, происходит разбор данных, полученных из курсора в понятные остальному коду классы.
Зачастую удобно сделать класс, который будет содержать текущее соединение с БД в своем поле и методы, делающие внутри один или несколько SQL-запросов, имеющих смысл с точки зрения основной логики программы. Этот код НЕ должен сам создавать соединение, воспользуйтесь Dependency Injection. Он так же не должен управлять транзакциями. Благодаря этому можно в дальнейшем комбинировать вызовы его методов. Также стоит избегать использования в интерфейсе этого класса слишком абстрактных методов, чтобы не переносить детали работы с БД в слой бизнес-логики.
Бизнес-логика
Этот слой содержит код обработки конкретных сценариев использования программы (use cases), то есть основную логику программы. Она абстрагирована от деталей работы базы данных или представления данных для пользователя. Для работы с базой данных она обращается к соответствующим адаптерам. Именно бизнес-логика знает о том, какие операции с базой данных являются неделимыми и управляет транзакциями.
Бизнес-логика не знает о том, откуда взялся адаптер БД, а просто использует его.
Контроллеры и представления
По сути это адаптеры, связывающие ваше приложение с его пользователями. Это могут быть view-функции веб-фреймворка, хэндлеры в телеграм боте, задачи celery, cron джобы и т.п.
Они реагируют на возникающие в вашем фреймворке события и вызывают бизнес-логику для его обработки. Контроллеры обрабатывают входящие данные, трансформируют их в понятные бизнес-логике структуры, а представления делают обратные преобразования.
Так как обрабатываемые события имеют понятный жизненный цикл, а также потому что мы технически не можем конкурентно использовать одно соединение БД, именно тут мы можем создавать наши соединения. Однако, так как настройка соединения выходит за рамки задачи контроллера, он должен создавать его не сам, а с помощью какой-то фабрики, получаемой из интеграционного слоя.
Если же фреймворк предоставляет механизм middleware, то такой объект также имеет представление о жизненном цикле события и может создавать соединение и передавать в контроллеры нужные объекты. Зачастую именно такой подход удобнее.
Интеграционный слой
Задача этого слоя собрать наше приложение из вышеописанных частей. Здесь может быть чтение конфигурации, создание экземпляров основных классов, связь их друг с другом, внедрение зависимостей и т.п.
Сюда можно так же отнести некоторые мидлвари, которые мы используем только для создания и внедрения зависимостей, привязанных к жизненному циклу обрабатываемых событий.
Итого:
1. Адаптер БД реализует единичные действия с базой и скрывает SQL код
2. Бизнес-логика оперирует транзакциями и вызывает методы адаптеров
3. Контроллер вызывает один или несколько use case в рамках соединения которое он получил сам или из мидлвари.
В начале обработки чего-либо (веб-запроса, сообщения в телеге и т.п.) достаем соединение, в конце обработки - возвращаем туда, откуда достали.
Также стоит отметить, что соединение с БД не обязательно физически открывать каждый раз, стоит использовать пулы соединений для ускорения.
Дополнительные материалы:
* https://ru.wikipedia.org/wiki/Адаптер_(шаблон_проектирования)
* https://martinfowler.com/eaaCatalog/repository.html
* https://www.ozon.ru/product/144499396/