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

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

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

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

请分享你对这个问题的其他方面的想法,比如性能,代码开发难度和可维护性等。

Solutions Collecting From Web of "如何决定直接访问数据库和内容提供者?"

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

优点

  • 没有外部依赖性。
  • 数据库连接生命周期由ContentProvider处理。
  • 在意图之间的活动之间轻松地传递内容URI。
  • 简单的后台查询通过CursorLoader(或滚动你自己的)。

缺点

  • 如果你没有一个很好的例子,可以混淆。
  • 如果您有企业Java背景,ORM可能更为熟悉。

当我试图找出如何实现一个ContentProvider的时候,我在Google的I / O应用程序中倾倒了这个示例代码。 在做出决定之前,我至less要花一天时间对原型进行原型devise,以便获得第一手的权衡体验。

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

  • 您有通过ContentObservers收听您的数据的ContentObservers
  • ContentProviders本身并不是线程安全的,但它很容易实现线程安全
  • 游标可以通过ContentProvider的notifyChange被要求保持最新notifyChange
  • 您可以添加良好的抽象,而不会影响业务层。 以下是一个示例:您可以在应用程序中使用Android联系人。 明天你打算介绍自己的联系人(通过你自己的WebService)。 ContentProvider可以被修改,以非常优雅的方式同化这个需求。
  • JOIN表可以很好地通过一个很好的devise暴露出来,而不会混淆业务逻辑代码。 查看一些Android ContentProvider,如MediaStore或ContactsContract。 看看他们的CONTENT_URI定义

总而言之,ContentProvider是一个非常漂亮的Android概念,值得一试。 一旦你有了你的定义,增加对更多数据的支持并不是很困难。 那么就像在Helper类或业务逻辑类中编写数据库代码一样简单。

**编辑**下面是一个实用工具,从模型类生成内容提供商代码: https : //code.google.com/p/mdsd-android-content-provider/

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