Преимущества использования общей библиотеки доступа к данным для доступа к базе данных для небольших проектов с несколькими микросервисами
Уровень доступа к данным (DAL) — это концепция, которая существует уже много лет. Поэкспериментировав с этой концепцией в течение нескольких месяцев, я подумал, что сейчас самое время поделиться своими мыслями, а также тем, как я абстрагировал DAL
для своих небольших проектов (с несколькими серверными микросервисами) с помощью общей библиотеки доступа к данным :)
Обратите внимание, что мои внутренние микросервисы были разработаны с использованием Spring Boot.
Для чего нужен уровень доступа к данным (DAL)?
Основная идея DAL
заключается в абстракции. Это уровень, который отвечает за управление хранением данных (например, создание, чтение, обновление, удаление). Вот некоторые из причин для реализации DAL
:
- Обеспечьте гибкость замены базовой базы данных/источника данных. Например. переход с MySQL на MongoDB.
- Абстрагируйте и отделите логику доступа к данным от бизнес-логики, позволяя обоим уровням развиваться независимо.
- Инкапсулируйте данные, чтобы любой микросервис мог взаимодействовать с данными
Каждый разработчик/инженер в той или иной степени реализует концепцию DAL
. Это может быть в форме использования объекта доступа к данным (DAO), объекта передачи данных (DTO) или просто разделения логики доступа к базе данных.
Знакомство с библиотекой доступа к данным
Концепции DAL
можно реализовать в кодовой базе вашего микросервиса. Однако, если вы работаете с несколькими микросервисами, вы можете захотеть еще больше абстрагировать DAL
, внедрив общую библиотеку доступа к внешним данным.
Библиотека доступа к данным — это настраиваемая внешняя библиотека, содержащая всю логику доступа к данным (операции CRUD).
Отказ от ответственности. Это анти-шаблон для микросервисной архитектуры. Следуя шаблону микросервисной архитектуры (единая ответственность и слабая связь), каждый микросервис должен иметь свою собственную базу данных и, следовательно, не иметь общей библиотеки доступа к данным.
Однако не у всех есть возможность иметь базу данных для каждого микросервиса из-за затрат и усилий по обслуживанию. Это особенно верно, когда вы находитесь в процессе перехода от монолитной к микросервисной архитектуре или когда у вас очень маленький проект.
В этой статье я в основном сосредоточусь на небольших проектах. Следовательно, я буду использовать единую общую базу данных для всех постоянных данных моего микросервиса. Для проектов с общей базой данных вы можете либо иметь общую общую библиотеку доступа к данным, либо сгруппировать библиотеку доступа к данным по функциям.
Вариант A: Общая библиотека доступа к данным
Наличие общей библиотеки доступа к внешним данным особенно полезно, если у вас небольшой проект, поскольку он позволяет централизовать всю логику доступа к данным в одной библиотеке. Ключевым преимуществом является то, что вам нужно будет поддерживать и модифицировать только одну библиотеку, а недостатком является то, что общая библиотека будет иметь избыточную логику для всех ваших микросервисов.
Кроме того, вы должны учитывать одну вещь — управление версиями библиотек.
- Если вы публикуете свою библиотеку, вам понадобится способ проверять все ваши микросервисы, использующие библиотеку, всякий раз, когда вы обновляете библиотеку.
- Если вы соедините его с Monorepo, вам не нужно будет беспокоиться об управлении версиями, поскольку ваши тестовые примеры сообщат вам, на какие микросервисы влияют модификации библиотеки.
Вариант B: группировка библиотеки доступа к данным по функциям
Чтобы предотвратить слишком много избыточной логики в библиотеке доступа к данным, вместо одной общей библиотеки доступа к данным для всех ваших микросервисов вы можете создать несколько библиотек доступа к данным и сгруппировать их по функциям. Это во многом зависит от размера вашего проекта, а также от того, сколько людей работает над проектом.
Однако обратите внимание, что наличие слишком большого количества библиотек доступа к данным также может создать трудности при их обслуживании. Когда это происходит, вам следует переосмыслить всю архитектуру микросервиса.
Как внедрить библиотеку доступа к данным
Независимо от того, используете ли вы общую общую библиотеку доступа к данным или библиотеку множественного доступа к данным, шаги по реализации внешней библиотеки одинаковы. Чтобы реализовать библиотеку доступа к данным, нам потребуется создать библиотеку со следующими компонентами.
# 1 — Объект передачи данных (DTO) и сущность
Шаблон Data Transfer Object (DTO) — это шаблон проектирования, который позволяет нам отделить уровень доступа к данным (DAL) и уровень бизнес-службы, как показано ниже.
DTO
действует как контракт на передачу данных между клиентом (бизнес-уровень) и библиотекой (уровень доступа к данным), но не внутренними компонентами библиотеки. Поскольку клиент взаимодействует только с использованием DTO
, это позволяет нам иметь большую гибкость для изменения внутренних компонентов библиотеки, не затрагивая клиента, пока DTO
не меняется.
Примечание. Вы можете рассматривать
DTO
как объект, который передает данные между бизнес-уровнем и уровнем данных, аEntity
— это объект, представляющий схему/таблицу базы данных.mapper
действует как мост для преобразования междуDTO
иEntity
и наоборот.
#2 — Объект доступа к данным (DAO)
Шаблон Data Access Object (DAO) — это шаблон проектирования, предоставляющий абстрактный интерфейс для взаимодействия с базой данных. Шаблон DTO
обрабатывает передачу данных, а шаблон DAO
обрабатывает логику CRUD.
DAO
инкапсулирует логику доступа к данным для бизнес-требований микросервиса. Это позволяет нам легко переключать базовую логику доступа к данным, не затрагивая бизнес-логику (например, изменения базы данных/схемы/логики).
Примечание. Вы можете думать о
DAO
как об интерфейсе с логикой CRUD. Например. создать нового пользователя, обновить информацию о пользователе, удалить пользователя и т. д.
Однако важно не усложнять DAO
сложной бизнес-логикой, поскольку ее лучше оставить на бизнес-уровне.
#3 — Интеграционное тестирование
Здесь следует описать два типа интеграционного тестирования.
- Тестирование интеграции с базой данных — . Это необходимо, чтобы проверить, работает ли вся логика DAO с базой данных. Например. Увеличение версии базы данных.
- Тестирование интеграции между микросервисом и библиотекой доступа к данным. Это позволяет нам быстро выявлять любые затронутые изменения при обновлении библиотеки доступа к данным.
Вот и все! Это 3 основных компонента, которые вам понадобятся для реализации библиотеки доступа к данным.
Заключение. Является ли библиотека доступа к данным хорошей идеей?
Это действительно зависит! Я бы порекомендовал его, если вы работаете над небольшими проектами. Чаще всего вы не будете запускать одну базу данных для каждого микросервиса с самого начала. Вместо этого у вас, вероятно, будет единая общая база данных из-за стоимости и простоты.
В таких случаях очень полезно иметь общую библиотеку доступа к данным (с применением DAL
концепций), которую можно использовать в нескольких микросервисах, поскольку она обеспечивает хороший уровень абстракции для обслуживания кода. Это также очень удобно, поскольку вам нужно управлять только одной общей библиотекой доступа к данным для всех операций, связанных с базой данных. Более того, это улучшает читаемость кода и побуждает разработчиков/инженеров к написанию интеграционных тестов. Однако обратите внимание, что, поскольку это общая библиотека доступа к данным, библиотека доступа к данным будет заполнена большим количеством избыточных кодов.
Примечание. Даже если вы не используете общую базу данных, вы все равно можете применять концепции уровня доступа к данным или даже абстрагировать логику в библиотеку доступа к данным.
Вот и все! Это краткое изложение того, что я изучил и применил, что я написал в контексте небольших проектов с общими базами данных. Это определенно не то, что можно применить ко всему, особенно когда общая база данных и общая библиотека доступа к данным вводят связь с вашей архитектурой. При этом я надеюсь, что эта статья поможет всем новым разработчикам/инженерам узнать больше о концепциях DAL
.
Если вам понравилась эта статья, пожалуйста, подпишитесь на меня, чтобы узнать больше! В продолжение этой статьи я приведу пример того, как реализовать и протестировать библиотеку доступа к данным в Spring Boot.
Спасибо за чтение :)
Повышение уровня кодирования
Спасибо, что являетесь частью нашего сообщества! Перед тем, как ты уйдешь:
- 👏 Хлопайте за историю и подписывайтесь на автора 👉
- 📰 Смотрите больше контента в публикации Level Up Coding
- 💰 Бесплатный курс собеседования по программированию ⇒ Просмотреть курс
- 🔔 Подписывайтесь на нас: Twitter | ЛинкедИн | "Новостная рассылка"
🚀👉 Присоединяйтесь к коллективу талантов Level Up и найдите прекрасную работу