至少在纸面上，我理解Content Provider与直接访问SQLiteDatabase之间的基本区别。我的应用程序有一个正常运行的原型，目前只是直接命中数据库。我没有使用Content Provider模式的任何经验，但我发现我需要与另一个应用程序共享一些数据。
我只会分享大约2个表中的2个，所以我想知道我是否应该完全重做数据层以遵循Content Provider模式，或者只是通过Content Provider公开这些表为了其他应用程序而仍然直接访问主应用程序中的数据库。
我遇到的原型问题之一就是我有一些相当复杂的事务，而我为编写这些代码而编写的代码设计得并不是特别好，而且根本不可重用。当我为这个应用程序添加更多功能时，我将需要一个设计更好的数据访问层，在我开始自己创建之前，是否有人知道任何有关此类事物的设计模式的优秀资源？另外，如果我需要使用Content Provider路由，我是否可以完全控制数据库事务？
答案 0 :(得分：6)
我认为只要让内容提供商拥有您所需的功能，并且直接位于您的直接数据库代码之上，我认为您不应该遇到问题。内容提供者实际上只是访问结构化数据的抽象，看起来非常像SQLite。 :)如果应用程序的各个内部部分直接访问与提供程序相同的数据库，只要两个代码很好地一起播放，它应该没问题。
我实际上不是绝对的粉丝，“你必须始终使用内容提供商。”如果您不需要内容提供商，请不要使用;如果更容易，只需直接使用SQLite。如果您需要一个内容提供商来与其他应用程序进行某些特定的交互，请随意编写一个内容提供商，而不要让它成为一个很复杂的东西，支持您的应用程序在内部使用数据库执行的所有操作。如果这更容易，那很好。它还使您无意中将应用程序中的私人数据暴露给他人的可能性降低。
答案 1 :(得分：0)
不要引用我这个，但我很确定内容提供商是一种抽象方式来提取数据到对象的方式。这样，您的对象可以只与提供者通信，而不关心实现，即数据的存储方式/位置。也许您可能希望在将来提供一些其他方式来存储您的数据，并且使用内容提供程序范例将为您节省大量的返工，因为它只是基于接口的通信。
我会尽可能地使用Android设计模式。说实话，现在看一下我真的应该在我的项目中这样做。