我想在回收器 View 中呈现一些复杂对象的名称/基本属性列表(即它们由其他对象的多个集合组成)，然后在用户选择时获取完整对象。例如，顶级对象是“播放脚本”，每个对象都包含由与播放脚本关联的“ Actor ”之一说出的许多“台词”。
我正在尝试使用 Android 架构组件来执行此操作，并且(使用 Florian @codinginflow.com 的教程)成功使用 Room 创建了简化的 Play_Script 类、DAO 和存储库。我还在 ASP.Net 中创建了一些基本的 REST Web 服务，可以提供来自 MySQL 数据库的数据。
令我震惊的是，我要走的路径将表现不佳，并使用过多的网络带宽来获取大量我不会使用的数据。我获取每个播放脚本(包括其口语等)，以便我拥有播放脚本“名称”和“描述”属性来填充回收器。
过去，我只需“从 Play_Script 中选择 ID、名称、描述”，一旦用户做出选择，我就会使用 ID 作为 key 来获取我需要的其他所有内容。我怀疑我在数据实体的设计中遗漏了一些基本的东西，但无法想出任何关键字来让我搜索这种常见任务做得很好(/根本)的示例。
请你帮这个菜鸟解决他的第一个问题吗？
干杯， Z
5 月 15 日更新: 虽然我还没有得到回复，但从最近几周我读到的内容(例如依赖注入(inject))来看，我怀疑 Android 开发中没有针对此类事情的通用方法。人们通常要么检索大量数据，然后使用他们需要的数据，要么构建多个 Web 服务 API 来返回稀疏数据，其中包括客户端可以在需要时用于扩展的 key 。例如，您可以同时创建“plays_light”和“plays_detail”获取 API。
最佳答案
我的解决方案与我 5 月的更新完全相同 - 即扩展 Web API 并提供许多返回不同粒度信息的类似调用。它不是特别优雅，我怀疑可能有更好的方法，但它有效。一般来说，我发现用户往往需要较少的父实体细节，而当我们涉及到单个子/孙子实体时，需要更多细节。
我现在确实意识到为什么有些应用程序如此缓慢:在 Web 服务设计中很容易偷懒，只返回大量数据 - 客户端只会使用其中的一小部分 - 并通过说服自己来证明这一点这个单一的 API 将是普遍适用的，因此对于任何拿起我的代码的人来说都更容易理解。
同样，这可能是我的经验不足，但我发现通过 API 调用检索的 Android 端关系数据的本地缓存非常笨拙 - 大量存储外键，然后重新解析 json 以将数据获取到 SQLite 表中。我本来希望 Dagger 在简化这个过程中比目前的情况更有用。实际上，我只是为了保持理智，解开了一大堆与 Dagger 相关的代码。不确定我是否完全成功!
仍然非常欢迎更好的答案。 Z
关于java - 如何将代码/描述扩展到复杂的对象？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55145796/