Как расширить код / ​​описание на сложный объект?

Question

Я хочу представить список имен / базовых атрибутов некоторых сложных объектов (т. Е. Они состоят из нескольких коллекций других объектов) в представлении переработчика, а затем получить полный объект по выбору пользователя.Например, объектами верхнего уровня являются «Сценарии воспроизведения», и каждый из них содержит несколько «Разговорных линий», на которых говорит один из «Актеров», связанных со сценарием воспроизведения.

Я пытаюсь использоватьКомпоненты архитектуры Android для этого и (используя руководства Florian @ codinginflow.com) успешно использовали Room для создания упрощенного класса Play_Script, DAO и репозитория.Я также создал несколько базовых веб-сервисов REST в ASP.Net, которые могут обслуживать данные из базы данных MySQL.

Меня поражает, что путь, по которому я иду, будет работать плохо и будет использовать избыточную пропускную способность сети.много данных, которые я не буду использовать.Я получаю каждый Play Script (включая его Spoken Lines и т. Д.) Только для того, чтобы у меня были атрибуты Play Script «Name» и «Description» для заполнения Recycler.

В старые времена я просто«SELECT ID, Name, Description FROM Play_Script», и как только пользователь сделал свой выбор, я бы использовал ID в качестве ключа, чтобы получить все остальное, что мне было нужно.Я подозреваю, что мне не хватает чего-то фундаментального в дизайне моих сущностей данных, но я не могу найти ни одного ключевого слова, которое позволило бы мне искать примеры выполнения этой типичной задачи (/ вообще).

Не могли бы вы помочь этому SO noob с его 1-м вопросом?

Приветствия, Z

Обновление от 15 мая: Хотя я не получил ответа отто, что я читал в последние недели (например, «Внедрение зависимостей»), я подозреваю, что в разработке для Android такого подхода не существует.Похоже, что люди обычно либо извлекают обширные данные, а затем используют то, что им требуется, либо создают несколько API-интерфейсов веб-служб, чтобы возвращать разреженные данные, которые включают ключи, которые клиент может использовать для расширения при необходимости.Так, например, вы можете создать API-интерфейс Play_light и Play_detail.

Answer 1

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

Теперь я понимаю, почему некоторые приложения так медленны: легко быть ленивым в дизайне веб-службы и просто возвращать множество данных - только часть из которых будет использоваться клиентом - и оправдать это, убедив себя этот единый API будет универсально применим, и, следовательно, его будет легче понять любому, кто поймет мой код.

Опять же, это может быть моей неопытностью, но я нахожу локальное кеширование реляционных данных на стороне Android, получаемых с помощью вызовов API, довольно неуклюжим - много хранения внешних ключей, а затем повторный анализ json для получения данных в таблицах SQLite. Я надеялся, что Кинжал был бы более полезен в упрощении этого, чем это оказалось до сих пор. Я на самом деле разгадал весь код, связанный с Dagger, просто чтобы сохранить свое здравомыслие. Не уверен, что я был полностью успешным!

Лучшие ответы по-прежнему очень приветствуются. Z