Совместное использование POJO между бэкэндом Java и приложением Android - PullRequest
0 голосов
/ 27 ноября 2018

Я разрабатываю приложение для Android с моим другом.В настоящее время я отвечаю за бэкэнд, пока она работает над частью Android.Бэкэнд разработан на Java с использованием функций Lambda, работающих в AWS Amazon Cloud.Интерфейс и бэкэнд полностью отделены (лямбда-функции доступны через REST API), за исключением POJO, используемых с обеих сторон.POJO сериализуются приложением в JSON при вызове API и снова десериализуются в POJO (те же самые) с помощью бэкэнда при обработке запросов API.

Мы хотим, чтобы POJO с обеих сторон были абсолютно одинаковыми по очевидным причинам.но мы задаемся вопросом, как правильно это сделать.Мы видим следующие два варианта:

1) Просто скопируйте код с обеих сторон.Недостатком этого является независимое изменение общего кода, что рано или поздно приведет к смещению.

2) Переместите POJO в отдельную библиотеку и включите ее в качестве зависимости с обеих сторон.Это кажется более правильным способом решения этой проблемы, но как мы можем гарантировать, что и я, и мой друг знаем, что POJO был изменен?Допустим, я удалил одно поле из POJO и создал новую версию разделяемой библиотеки.Я помещаю изменения в наш репозиторий, а затем ... говорю моей подруге, что я внес некоторые изменения, чтобы она вытащила их, создала новую версию и включила ее в свой проект?

Есть ли другой (лучший) способрешить эту проблему?В настоящее время серверная часть построена с помощью Maven, но я могу переключиться на Gradle, если это поможет автоматизировать вещи и сделать наш код согласованным (Android Studio вынуждает собирать Gradle).

Я нашел похожие вопросы других людей, но они были либонемного отличается или остался без ответа:

Совместное использование POJO между проектом Android и бэкенд-проектом Java

Совместное использование одной библиотеки Java между бэкэндом Android и Java (gradle)

Совместное использование кода между бэкэндом Java и приложением Android

1 Ответ

0 голосов
/ 27 ноября 2018

Конечно, есть много других способов сделать это, лучше или нет;Я оставлю это на ваше усмотрение.

Но перед тем, как делиться POJO, я прошу вас сделать шаг назад и взглянуть на вашу архитектуру.По сути, вы получили:

  1. бэкэнд Java с REST API, поддерживающий полезную нагрузку JSON
  2. приложение Android, способный выполнять вызовы REST и десериализовать полезные нагрузки JSON.

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

Как насчет того, чтобы заглянуть в будущее, когда вы добавите больше компонентов в свою архитектуру, скажем:

iOS-приложение Поддержка Kotlin для Android-приложения

Будет ли ваше желание поделиться кодом POJO по-прежнему без изменений?Возможно, нет.

Из того, что я вижу, вы должны спроектировать и разработать бэкэнд REST и клиент с поддержкой REST .Это все.Это должно быть практическим результатом.

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

Этот подход может иметь определенные преимущества.Например:

  1. Вы сможете делиться обновлениями сейчас и в будущем, в соответствии с вашими требованиями.
  2. Это также делает вашу модульность (или разделение) лучше, потому что бэкэнд и клиент не связаны требованиями к использованию POJO.Например, вы можете использовать Data class, если решите использовать Kotlin в своем клиенте.
  3. Вы можете использовать версионную схему для будущего, когда клиент не может идти в ногу с бэкэндом или бэкэнд должен обновляться независимо.
  4. и более
...