Сохранение REST API JSON в RDBMS

Question

Есть WebApp с REST API.Я должен использовать API, который находится в формате JSON, а затем сохранить его в RDBMS.JSON - это в основном список свойств и под-свойств.Я должен сопоставить их со столбцами БД.

Схема БД еще не создана, как мне кажется, подходящей.То, что я ищу, - это лучший способ отобразить JSON в Java DTO, а затем DTO в Entity.Я планировал использовать JACKSON для сопоставления JSON и DTO.Я мог бы или не мог сопоставить все свойства.Затем на следующем шаге я планировал написать ручные средства отображения, которые будут отображать DTO в Entity.

Я должен использовать RDBMS (MySQL) вместо NoSQL, потому что другие инструменты, которые будут считывать данные из БД, основаны на SQL-запросах.

РЕДАКТИРОВАТЬ: Коммерческие инструменты отчетности, которые должны использовать СУБД, имеют некоторые ограниченные возможности SQL-запросов, не могут выполнять какие-либо сложные SQL или бизнес-логики там.Поэтому я не могу сохранить JSON как строку, а затем токенизировать ее позже в инструментах отчетности.

Есть идеи по этому поводу?Я знаю, что это может быть сделано напрямую JSON для Entity, но есть совет не делать этого, как в этом совете: Отображение объекта JSON в Hibernate Entity

Есть ли лучший способ сделать этоили мой строгий подход хорош для старта?

Answer 1

В целом подход правильный. Но детали зависят от того, какие фреймворки / ORM вы собираетесь использовать (если есть).

Если вы хотите использовать JPA / Hibernate для персистентности - вам понадобится класс (ы) Entity, которые никогда не должны использоваться в качестве DTO. Если у вас будет какое-то пользовательское постоянство, вы, вероятно, можете вообще пропустить классы сущностей и просто использовать DTO для заполнения параметров запроса.

Но самым простым и наиболее распространенным способом реализации такого решения было бы использование Spring Framework, который автоматически сопоставлял бы ваш JSON с DTO, используя Jackson, и Spring Data JPA для сохранения.

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

Answer 2

Только одна POJO модель

Я согласен, что использование одной и той же структуры POJO для библиотек Hibernate и Jackson, вообще говоря, не лучший вариант. Но это также зависит от конкретных сценариев, которые вам нужно реализовать. В вашем случае вам нужно загрузить данные из REST API и сохранить результат в DB. Таким образом, в основном вы будете вызывать INSERT запросов в 90% случаев. Таким образом, вы можете сохранять структуру POJO очень простой, не беспокоясь о проблемах lazy-loading В этом сценарии использование такой же структуры POJO не так уж плохо. Связанный вопрос / ответ говорит только о проблемах с чтением и разоблачением структуры DB на REST API, что не относится к данному вопросу.

Вам также необходимо выяснить, чем отличается модель DB от модели JSON. Если они похожи, и вы можете сказать 1:1, нет необходимости создавать дополнительный слой.

Две POJO модели

В этом сценарии вам необходимо создать две модели POJO: одну для обработки десериализации JSON и одну для работы с DB через ORM. В этом сценарии самой большой проблемой является сопоставление этих двух моделей. Кроме того, изменения в REST API распространяются на каждый слой. Вы можете использовать библиотеки карт курса, такие как Dozer , Orika , MapStruct или другие, но всегда есть необходимость поддерживать этот слой. С другой стороны, это очень безопасное решение, потому что вы можете управлять отображением на JSON и DB отдельно и хранить разные структуры без большого количества аннотаций или пользовательских десериализаторов, адаптеров и т. Д. С другой стороны, если эти две модели действительно разные, это Решение самое лучшее.

Коллекции и одна POJO модель

Существует также третий вариант, который я вижу, и он использует библиотеку Java collection для обработки JSON полезных нагрузок. JSON Object соответствует Map<String, Object> и JSON array соответствует List<Object>. Jackson автоматически позаботится о выборе правильных типов, и вам нужно только сопоставить эти коллекции с POJO моделью, используемой на стороне ORM. Это решение устраняет необходимость сохранять две модели, но усложняет отображение слоя и делает его нечетким.

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