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

我正在编写一个由业务逻辑和UI部分组成的应用程序。 BL和UI都有相当大量的数据存储和访问/修改。在大多数情况下，存储数据的更改应立即由UI反映。如何决定直接访问数据库和内容提供者？

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

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

请对这个问题的其他方面，如性能，代码开发和维护的难易程度等，分享您的想法

2011-08-11 Asahi

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

优点：

缺点：

当我试图弄清楚如何实现ContentProvider时，我倾倒了Google's I/O应用程序中的示例代码。在做出决定之前，我至少会花一天时间对原型进行原型设计，以便您可以亲身体验权衡。

2011-08-11 14:58:06

谢谢。您是否注意到内容提供商与直接数据库访问相比存在任何性能问题？ – Asahi

@Asahi内容提供者是一个非常简单的抽象。我没有看到使用它们的任何性能问题。 –

IMO：单APK ==通过持久层的直接访问。多重APK（无论是您自己的，还是希望将数据访问权限提供给其他人的应用程序）==内容提供商通过简单的必要性。

2011-08-11 14:35:49 Earl

比方说，我不希望共享的数据。你能估计/比较开发所需的努力吗？保持？可能的性能问题？ – Asahi

内容提供者将是一个额外的抽象层，具有必要的开发时间，维护和性能打击 - 这些取决于许多事情，包括但不限于应用程序的性质和作为程序员。简单地将应用程序中的问题分开以包含持久层是最基本的工作，并且将成为度量性能影响的基准。 – Earl

谢谢。我不能不同意你的答案，但他们太笼统了。你可以说得更详细点吗？根据您的经验，哪些应用程序/功能适用于内容提供商，哪些不适用？假设编码员对两种模型都有一定的经验。 – Asahi

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

你必须通过ContentObservers
ContentProviders自己听你的数据不是线程安全的方式，但它是很容易实现线程safetly
游标可以要求自己保持了通过ContentProvider的notifyChange
您可以添加良好的抽象，而不会影响业务层。以下是一个示例：您可以在应用程序中使用Android联系人。明天你打算介绍自己的联系人（通过你自己的WebService）。 ContentProvider可以修改，以非常优雅的方式吸收这个需求。
JOIN表可以很好地通过一个很好的设计而不会混淆业务逻辑代码。查看一些Android ContentProvider，如MediaStore或ContactsContract。查看他们的CONTENT_URI定义

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

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

2011-08-11 14:58:31

回答