如何将code/description展开为一个复杂的对象？
How to expand code/description to a complex object?
我想在回收器视图中显示一些复杂对象（即它们由其他对象的多个集合组成）的 names/basic 属性列表，然后在用户选择时获取完整对象。例如，顶级对象是 "Play Scripts"，每个对象都包含与播放脚本关联的 "Actors" 之一所说的一些 "Spoken Lines"。
我正在尝试使用 Android 架构组件来执行此操作并且（使用 Florian @ codinginflow.com 的教程）成功地使用 Room 创建了一个简化的 Play_Script class、DAO 和存储库。我还在 ASP.Net 中创建了一些基本的 REST Web 服务，它可以提供来自 MySQL 数据库的数据。
令我震惊的是，我所走的道路将表现不佳，并使用过多的网络带宽获取大量我不会使用的数据。我得到了每个播放脚本（包括它的口语等），这样我就有了播放脚本 "Name" 和 "Description" 属性来填充 Recycler。
在过去，我只是 "SELECT ID, Name, Description FROM Play_Script"，一旦用户做出选择，我就会使用 ID 作为密钥来获取我需要的所有其他内容。我怀疑我在数据实体的设计中遗漏了一些基本的东西，但无法想出任何关键字来让我搜索这种常见任务做得很好的例子（/完全）。
你能帮这个菜鸟解决他的第一个问题吗？
干杯，
Z
5 月 15 日更新：
虽然我还没有收到回复，但根据我最近几周阅读的内容（例如重新依赖注入），我怀疑 Android 开发中没有针对此类事情的全面方法。看起来人们通常要么检索大量数据然后使用他们需要的数据，要么构建多个 Web 服务 API 到 return 稀疏数据，其中包括客户端可以在需要时用于扩展的密钥。因此，例如，您可以同时制作 "plays_light" 和 "plays_detail" Get API。
我的解决方案与我 5 月的更新完全相同 - 即扩展网络 API 并提供许多类似的调用 return 不同粒度的信息。它不是特别优雅，我怀疑可能有更好的方法，但它确实有效。总的来说，我发现用户倾向于在父实体中需要更少的细节，而当我们到达个人 children/grandchildren.
时需要更多的细节
我现在明白为什么有些应用程序这么慢了：在 Web 服务设计中很容易偷懒，只是 return 加载数据 - 客户端只会使用其中的一部分 -并通过说服自己单个 API 将普遍适用并因此让任何拿起我的代码的人更容易理解来证明这一点。
同样，这可能是我的经验不足，但我发现通过 API 调用检索的 Android 端的关系数据的本地缓存非常笨拙 - 大量存储外键然后 re-parsing json 将数据放入 SQLite 表中。我希望 Dagger 在简化这个方面比到目前为止更有用。我实际上解开了一大堆 Dagger-related 代码只是为了保持理智。不确定我是否完全成功！
更好的答案还是非常欢迎的。
Z
我想在回收器视图中显示一些复杂对象（即它们由其他对象的多个集合组成）的 names/basic 属性列表，然后在用户选择时获取完整对象。例如，顶级对象是 "Play Scripts"，每个对象都包含与播放脚本关联的 "Actors" 之一所说的一些 "Spoken Lines"。
我正在尝试使用 Android 架构组件来执行此操作并且（使用 Florian @ codinginflow.com 的教程）成功地使用 Room 创建了一个简化的 Play_Script class、DAO 和存储库。我还在 ASP.Net 中创建了一些基本的 REST Web 服务，它可以提供来自 MySQL 数据库的数据。
令我震惊的是，我所走的道路将表现不佳，并使用过多的网络带宽获取大量我不会使用的数据。我得到了每个播放脚本（包括它的口语等），这样我就有了播放脚本 "Name" 和 "Description" 属性来填充 Recycler。
在过去，我只是 "SELECT ID, Name, Description FROM Play_Script"，一旦用户做出选择，我就会使用 ID 作为密钥来获取我需要的所有其他内容。我怀疑我在数据实体的设计中遗漏了一些基本的东西，但无法想出任何关键字来让我搜索这种常见任务做得很好的例子（/完全）。
你能帮这个菜鸟解决他的第一个问题吗？
干杯， Z
5 月 15 日更新： 虽然我还没有收到回复，但根据我最近几周阅读的内容（例如重新依赖注入），我怀疑 Android 开发中没有针对此类事情的全面方法。看起来人们通常要么检索大量数据然后使用他们需要的数据，要么构建多个 Web 服务 API 到 return 稀疏数据，其中包括客户端可以在需要时用于扩展的密钥。因此，例如，您可以同时制作 "plays_light" 和 "plays_detail" Get API。
我的解决方案与我 5 月的更新完全相同 - 即扩展网络 API 并提供许多类似的调用 return 不同粒度的信息。它不是特别优雅，我怀疑可能有更好的方法，但它确实有效。总的来说，我发现用户倾向于在父实体中需要更少的细节，而当我们到达个人 children/grandchildren.
时需要更多的细节我现在明白为什么有些应用程序这么慢了：在 Web 服务设计中很容易偷懒，只是 return 加载数据 - 客户端只会使用其中的一部分 -并通过说服自己单个 API 将普遍适用并因此让任何拿起我的代码的人更容易理解来证明这一点。
同样，这可能是我的经验不足，但我发现通过 API 调用检索的 Android 端的关系数据的本地缓存非常笨拙 - 大量存储外键然后 re-parsing json 将数据放入 SQLite 表中。我希望 Dagger 在简化这个方面比到目前为止更有用。我实际上解开了一大堆 Dagger-related 代码只是为了保持理智。不确定我是否完全成功！
更好的答案还是非常欢迎的。 Z