我正在编写一个由业务逻辑和UI部分组成的应用程序。无论是BL还是UI，都有大量的数据需要存储和访问/修改。在大多数情况下，对存储数据的更改应该立即由UI反映出来。
如何决定是否使用直接访问数据库?内容提供者?
我已经读了一些关于主题(1,2)的文章，我理解这两个选项之间的区别。
请分享您对问题的其他方面的想法，例如性能，代码开发的难度级别和可维护性等
在我编写的应用程序中，我发现一旦你通过了学习曲线，实现ContentProvider是相当容易的。
优点:
- 没有外部依赖。 数据库连接生命周期由ContentProvider处理。
- 在Intent中的activity之间轻松传递内容uri。
- 简单的后台查询通过CursorLoader(或滚动你自己的)。
缺点:
- 如果你手边没有一个好的例子，
- 可能会令人困惑。 如果你有企业Java背景，ORM可能会更熟悉。
当我试图弄清楚如何实现ContentProvider时，我在Google的I/O应用程序中倾注了示例代码。在你做决定之前，我建议你至少花一天时间做一个原型，这样你就可以获得第一手的权衡经验。
我建议你花额外的时间和精力来编写你的ContentProvider。内容提供者不仅仅是为了共享数据访问。优势
- 你可以通过
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/
IMO:单个APK ==通过持久层直接访问。多个apk(无论是你自己的还是想要为别人的应用提供数据访问)== Content Provider(内容提供商)。