如何决定直接数据库访问和内容提供商？

Question

我正在编写一个由业务逻辑和UI部分组成的应用程序.BL和UI都存储和访问/修改了大量数据.在大多数情况下,存储数据的更改应立即由UI反映.

我如何决定是否应该使用直接数据库访问？内容提供商？

我已经做了关于这个问题(一些阅读1,2),我理解这两个选项之间的差异.

请分享您对问题其他方面的看法,例如性能,代码开发难度和可维护性等.

Answer 1

在我编写的应用程序中,我发现一旦你超越了学习曲线,实现ContentProvider非常容易.

优点:

• 没有外部依赖.
• 数据库连接生命周期由ContentProvider处理.
• 在Intent中的活动之间轻松传递内容URI.
• 通过CursorLoader进行简单的背景查询(或自己滚动).

缺点:

• 如果你没有一个好的例子,可能会让人感到困惑.
• 如果您有企业Java背景,ORM可能更熟悉.

当我试图弄清楚如何实现ContentProvider时,我将示例代码倾注在Google的I/O应用程序中.在您做出决定之前,我至少会花一天时间对其进行原型设计,以便您可以获得权衡的第一手经验.

Answer 2

我建议花费额外的时间和精力来编写ContentProvider.ContentProviders不仅仅是共享数据访问权限.优点

• 您可以通过各种方式收听数据 ContentObservers
• ContentProviders本身不是线程安全的,但很容易实现线程安全
• 可以要求游标通过ContentProvider保持自己的最新状态 notifyChange
• 您可以在不影响业务层的情况下添加良好的抽象.以下是一个示例:您在应用程序中使用Android联系人.明天您计划介绍自己的联系人(通过您自己的WebService).可以修改ContentProvider以非常优雅的方式同化此要求.
• 通过漂亮的设计可以很好地展示JOIN表,而不会使业务逻辑代码混乱.查看一些Android ContentProvider,如MediaStore或ContactsContract.查看他们的CONTENT_URI定义

总而言之,ContentProvider是一个非常漂亮的Android概念,非常值得实现.一旦确定了定义,就不难添加对更多数据的支持.然后,就像在Helper类或业务逻辑类中编写数据库代码一样简单.

**编辑**这是一个从模型类生成内容提供者代码的实用程序:https://code.google.com/p/mdsd-android-content-provider/

Answer 3

IMO:单个APK ==通过持久层直接访问.多个APK(您自己或想要提供对其他人的应用程序的数据访问)==内容提供商的简单必要性.