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

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

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

我已经对这个主题做了一些阅读( 1,2 ),我理解这两个选项之间的区别。

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

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

优点

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

缺点

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

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

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

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

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

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

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