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

Question

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

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

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

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

Answer 1

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

<强>赞成：

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

<强>缺点：

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

当我试图弄清楚如何实现ContentProvider时，我倾注了Google's 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（您自己或想要向其他人的应用提供对数据的访问权限）==内容提供商的简单必要性。