Конечно, есть много других способов сделать это, лучше или нет;Я оставлю это на ваше усмотрение.
Но перед тем, как делиться POJO, я прошу вас сделать шаг назад и взглянуть на вашу архитектуру.По сути, вы получили:
- бэкэнд Java с REST API, поддерживающий полезную нагрузку JSON
- приложение Android, способный выполнять вызовы REST и десериализовать полезные нагрузки JSON.
Если вы заметили выше, стек технологий не включает POJO на любом уровне.Вы понимаете, о чем я?POJO - это деталь реализации для вас, и нет смысла делиться ею с вашими компонентами.
Как насчет того, чтобы заглянуть в будущее, когда вы добавите больше компонентов в свою архитектуру, скажем:
iOS-приложение Поддержка Kotlin для Android-приложения
Будет ли ваше желание поделиться кодом POJO по-прежнему без изменений?Возможно, нет.
Из того, что я вижу, вы должны спроектировать и разработать бэкэнд REST и клиент с поддержкой REST .Это все.Это должно быть практическим результатом.
Итак, возвращаясь к вашим требованиям к совместному использованию обновлений между бэкэндом и клиентом, вы можете совместно использовать схему JSON между двумя вместоделиться POJO.И после этого используйте автоматизированную систему (скажем, простой скрипт) для генерации POJO в бэкэнде и клиенте.
Этот подход может иметь определенные преимущества.Например:
- Вы сможете делиться обновлениями сейчас и в будущем, в соответствии с вашими требованиями.
- Это также делает вашу модульность (или разделение) лучше, потому что бэкэнд и клиент не связаны требованиями к использованию POJO.Например, вы можете использовать
Data class
, если решите использовать Kotlin в своем клиенте. - Вы можете использовать версионную схему для будущего, когда клиент не может идти в ногу с бэкэндом или бэкэнд должен обновляться независимо.
- и более