Преимущества использования общей библиотеки доступа к данным для доступа к базе данных для небольших проектов с несколькими микросервисами

Уровень доступа к данным (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 — Интеграционное тестирование

Здесь следует описать два типа интеграционного тестирования.

  1. Тестирование интеграции с базой данных — . Это необходимо, чтобы проверить, работает ли вся логика DAO с базой данных. Например. Увеличение версии базы данных.
  2. Тестирование интеграции между микросервисом и библиотекой доступа к данным. Это позволяет нам быстро выявлять любые затронутые изменения при обновлении библиотеки доступа к данным.

Вот и все! Это 3 основных компонента, которые вам понадобятся для реализации библиотеки доступа к данным.

Заключение. Является ли библиотека доступа к данным хорошей идеей?

Это действительно зависит! Я бы порекомендовал его, если вы работаете над небольшими проектами. Чаще всего вы не будете запускать одну базу данных для каждого микросервиса с самого начала. Вместо этого у вас, вероятно, будет единая общая база данных из-за стоимости и простоты.

В таких случаях очень полезно иметь общую библиотеку доступа к данным (с применением DAL концепций), которую можно использовать в нескольких микросервисах, поскольку она обеспечивает хороший уровень абстракции для обслуживания кода. Это также очень удобно, поскольку вам нужно управлять только одной общей библиотекой доступа к данным для всех операций, связанных с базой данных. Более того, это улучшает читаемость кода и побуждает разработчиков/инженеров к написанию интеграционных тестов. Однако обратите внимание, что, поскольку это общая библиотека доступа к данным, библиотека доступа к данным будет заполнена большим количеством избыточных кодов.

Примечание. Даже если вы не используете общую базу данных, вы все равно можете применять концепции уровня доступа к данным или даже абстрагировать логику в библиотеку доступа к данным.

Вот и все! Это краткое изложение того, что я изучил и применил, что я написал в контексте небольших проектов с общими базами данных. Это определенно не то, что можно применить ко всему, особенно когда общая база данных и общая библиотека доступа к данным вводят связь с вашей архитектурой. При этом я надеюсь, что эта статья поможет всем новым разработчикам/инженерам узнать больше о концепциях DAL.

Если вам понравилась эта статья, пожалуйста, подпишитесь на меня, чтобы узнать больше! В продолжение этой статьи я приведу пример того, как реализовать и протестировать библиотеку доступа к данным в Spring Boot.

Спасибо за чтение :)

Повышение уровня кодирования

Спасибо, что являетесь частью нашего сообщества! Перед тем, как ты уйдешь:

  • 👏 Хлопайте за историю и подписывайтесь на автора 👉
  • 📰 Смотрите больше контента в публикации Level Up Coding
  • 💰 Бесплатный курс собеседования по программированию ⇒ Просмотреть курс
  • 🔔 Подписывайтесь на нас: Twitter | ЛинкедИн | "Новостная рассылка"

🚀👉 Присоединяйтесь к коллективу талантов Level Up и найдите прекрасную работу