Статьи

Что нового в Джакарте NoSQL? (Часть 1): Введение в документ с MongoDB

Jakarta EE начинает с того места, где остановилась Java EE 8, но план развития в будущем будет сфокусирован на современных инновациях, таких как микросервисы, модульность и базы данных NoSQL. В этой статье будет рассказано о новейшей веховой версии этой новой спецификации и последующих действиях, направленных на то, чтобы сделать сообщество Jakarta EE еще более значительным в облаке.

Почему Джакарта NoSQL?

Блокировка поставщика — это одна из вещей, которую любой Java-разработчик должен учитывать при выборе баз данных NoSQL. Если есть необходимость в переключении, другие факторы включают время, потраченное на изменение, кривую изучения нового API для использования с этой базой данных, код, который будет потерян, уровень сохраняемости, который необходимо заменить. Jakarta NoSQL позволяет избежать большинства этих проблем с помощью API-интерфейсов связи. Jakarta NoSQL также имеет классы шаблонов, которые применяют шаблонный шаблонный шаблонный метод к операциям с базой данных. А Repositoryинтерфейс позволяет разработчикам Java создавать и расширять интерфейсы, причем реализация автоматически обеспечивается Jakarta NoSQL — для них автоматически будут реализованы запросы методов поддержки, созданные разработчиками.

Вам также могут понравиться:  Джакарта EE: Поколение IV — новая надежда

Чтобы было понятно, давайте создадим пример кода. На рисунке ниже показаны четыре разные базы данных:

  • ArangoDB
  • MongoDB
  • Couchbase
  • OrientDB

Что общего у этих баз данных?

Да, все они — базы данных NoSQL для документов, и они пытаются создать документ, кортеж с именем и саму информацию. Однако все они делают одно и то же с одной и той же целью поведения, но с другим классом, именем метода и так далее. Итак, если вы хотите переместить свой код из одной базы данных в другую, вам нужно изучить новый API и обновить весь код базы данных до цели кода API базы данных.

Благодаря спецификации связи мы можем легко переключаться между базами данных, просто используя базы данных драйверов, которые выглядят как драйверы JDBC. Таким образом, вам будет удобнее изучать новую базу данных NoSQL с точки зрения архитектуры программного обеспечения; мы можем легко и быстро перейти на другой NoSQL.

Покажи мне

код
API

Чтобы продемонстрировать, как работает Jakarta NoSQL, давайте создадим небольшой REST API; этот API будет работать в облаке с Platform.sh. API будет обрабатывать героев, и вся информация будет храниться в MongoDB. В качестве первого шага нам нужно установить зависимости, которые нужны Jakarta NoSQL:

  • Джакартский контекст инъекции зависимостей 2.0 . Внедрение зависимостей Jakarta Contexts определяет средства для получения объектов, которые максимизируют возможность повторного использования, тестируемости и удобства обслуживания по сравнению с традиционными подходами, такими как конструкторы, фабрики и локаторы служб. Думайте об этом как о клее для всего мира Джакарты.
  • Джакарта JSON Binding . Определяет структуру привязки для преобразования объектов Java в и из документов JSON.
  • Валидация бобов Джакарта 2.0 (необязательно). Валидация Jakarta Bean определяет модель метаданных и API для JavaBean и валидацию методов.
  • Eclipse MicroProfile Configuration (необязательно). Eclipse MicroProfile Config — это решение для настройки конфигурации из приложений Java.

XML