android - 在 Room 数据库实体上实现 Parcelable 是一种好习惯吗?

标签 android performance android-intent android-room parcelable

我正在复习我的 Android 开发技能,并且一直在研究架构组件。所以我使用 Room 注释创建了一个实体类以持久化到数据库,并在实体类上实现了 Parcelable 部分目的是为了将实体对象放入 Intent 对象并在 Activity/fragment 之间传递它。我只想知道这是否是一个好习惯。使用此类方法是否有任何缺点,例如数据库泄漏或安全漏洞?只是好奇。

最佳答案

I just want to know if this is a good practice.

恕我直言,在现代 Android 应用程序开发中,不,有几个原因,包括:

  • 存储库模式:Android 应用架构中的当前模式是隔离数据存储并将关注点转移到“存储库”对象中。存储库知道数据来源和去向的详细信息(Room、Realm、Retrofit 等)。应用程序的其余部分既不知道也不关心,因为应用程序的其余部分只是与存储库对话。使用此模式,您将在 Activity 和 fragment 之间传递标识符,而存储库将根据这些标识符移交模型对象。

  • 隐藏实现细节:您的 UI 应该使用一组理想的模型类,这些模型类不依赖于数据存储或传输的特定实现。这样,如果您选择更改您的实现(例如,从 Room 到 Realm),您的更改将保持独立并且对 UI 几乎没有影响。如果您使用存储库,存储库将负责将 Room 实体和 Retrofit 响应转换为应用其余部分知道如何使用的标准化模型对象。

  • 单一事实来源:一旦您开始通过 Intent extras 传递对象,您就在制作副本。如果您的应用程序的一部分随后希望修改该模型对象……应用程序的其余部分(持有数据的其他副本)将如何了解这些更改?理想情况下,您有一个带有反应式 API 的存储库,其中存储库是进行数据更改的一方。然后,它可以将数据更改通知其他相关方,提供模型对象的最新版本。

  • IPC 内存限制:每次您将 IntentstartActivity() 一起使用时,startActivityForResult()setResult() 等,Intent 的内容被传递给核心操作系统进程...即使正在启动的 Activity 在同一个进程中作为请求启动该 Activity 的代码。 Intent 的大小有内存限制(粗略地说,1MB 或更低)。传递完整的模型对象现在可能工作正常,但如果以后有人向模型添加 Bitmap 字段或其他内容,您可能会遇到麻烦。

关于android - 在 Room 数据库实体上实现 Parcelable 是一种好习惯吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/56058576/

相关文章:

java - Android端口扫描TCP服务器?

android - 可以将文本或字符串作为 sqlite android 中的主键

Android 在自定义 View 中管理配置更改(状态)

php - mysql:在查询中或在php中减去多个列?

performance - Haskell中合理有效的纯功能矩阵产品?

javascript - 等待一项发布完成后再开始另一项发布

java - 你能在 Kotlin/Java 中强制编译器警告或错误吗?

android - 在 Android 中分享图库中的图片

android - 如何获取从 onReceive() 触发的 Intent 的名称或类型

android - PendingIntent 的 onActivityResult