在Room数据库实体上实施Parcelable是一种好习惯吗? [英] Is it good practice implementing Parcelable on a Room database entity?

问题描述

我正在学习自己的Android开发技能，并且一直在使用Architecture Components.因此，我使用Room批注创建了一个实体类以保持对数据库的持久性，并在实体类上实现了Parcelable，部分目的是将实体对象放入Intent对象中并将其在活动/片段之间传递.我只想知道这是否是一个好习惯.使用诸如数据库泄漏或安全漏洞之类的方法有任何弊端吗?只是好奇.

I'm brushing on my Android dev skills and have been playing around with the Architecture Components. So I created an entity class using Room annotations for persistence to the database and implemented Parcelable on the entity class partly for the purpose of putting the entity object into an Intent object and passing it between activities/fragments. I just want to know if this is a good practice. Are there any cons of using such approaches such as database leaks or security flaws? Just curious.

推荐答案

我只想知道这是否是个好习惯.

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

恕我直言，在现代Android应用程序开发中，不可以，原因如下:

IMHO, in modern Android app development, no, for a few reasons, including:

• 存储库模式:Android应用程序体系结构中的当前模式是隔离数据存储并将关注转移到存储库"对象中.存储库知道数据来自何处和去向的详细信息(房间，领域，改造等).该应用程序的其余部分既不知道也不在乎，因为该应用程序的其余部分仅与存储库通信.使用这种模式，您将在活动和片段之间传递标识符，并且存储库将基于这些标识符移交模型对象.

• Repository pattern: The current pattern in Android app architecture is to isolate data storage and transfer concerns into a "repository" object. The repository knows the details of where the data is coming from and going to (Room, Realm, Retrofit, etc.). The rest of the app neither knows nor cares, as the rest of the app just talks to the repository. With this pattern, you would pass identifiers around between activities and fragments, and the repository would hand over model objects based on those identifiers.

隐藏实现细节:您的UI应该使用一组理想的模型类，这些模型类与数据存储或传输的特定实现无关.这样，如果您选择更改实现(例如，从Room更改为Realm)，则所做的更改将保持隔离状态，并且对UI的影响很小.如果您使用存储库，则该存储库将负责将Room实体和Retrofit响应转换为应用程序的其余部分都知道如何使用的标准化模型对象.

Hide implementation details: Your UI should work with an ideal set of model classes, ones that are not tied to particular implementations of data storage or transfer. That way, should you elect to change your implementation (e.g., from Room to Realm), your changes remain isolated and should have little effect on the UI. If you use a repository, the repository would be responsible for converting from Room entities and Retrofit responses into standardized model objects that the rest of the app knows how to use.

单一事实来源:一旦开始通过Intent Extras传递对象，就在制作副本.如果您的应用程序的一部分随后希望修改该模型对象，那么该应用程序的其余部分如何保存数据的其他副本，那么将如何知道这些更改?理想情况下，您的存储库带有反应式API，该存储库是进行数据更改的一方.然后，它可以将数据更改通知其他有关方面，从而提供模型对象的最新再现.

Single source of truth: Once you start passing objects around via Intent extras, you are making copies. If one part of your app then wishes to modify that model object... how will the rest of the app, holding other copies of the data, know about those changes? Ideally, you have a repository with a reactive API, where the repository is the party that makes the data changes. It can then notify other interested parties about the data changes, delivering an up-to-date rendition of the model object.

IPC内存限制:每次将Intent与startActivity()，startActivityForResult()，setResult()等一起使用时，该Intent的内容将被传递到核心OS进程...即使正在启动的活动与请求启动该活动的代码处于同一进程中. Intent的大小有内存限制(大约1MB或更低).传递完整的模型对象现在可能可以正常工作，但是稍后如果有人在模型中添加Bitmap字段或其他内容，则可能会遇到麻烦.

IPC memory limits: Every time you use an Intent with startActivity(), startActivityForResult(), setResult(), etc., the contents of that Intent are passed to a core OS process... even if the activity being started is in the same process as the code that is requesting that activity be started. There are memory limits for how big an Intent can be (roughly speaking, 1MB or lower). Passing full model objects around may work fine right now, but later if somebody adds a Bitmap field or something to the model, you can get in trouble.

这篇关于在Room数据库实体上实施Parcelable是一种好习惯吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！