内容提供者与直接访问数据库（事务管理）

Question

我至少在纸面上了解内容提供者和直接访问SQLite数据库的基本区别。我有一个适用于我的应用程序的函数原型，目前它只是直接访问数据库。我真的没有使用Content Provider模式的经验，但我发现我需要与另一个应用程序共享一些数据。

我只会共享12个左右的表中的2个，所以我想知道是否应该完全重做数据层以遵循Content Provider模式，或只是通过Content Provider公开这些表为了其他应用程序的缘故，仍然直接访问主应用程序中的数据库。

我与我的原型遇到的问题之一是我有一些相当复杂的交易，我写的代码让我工作的设计不是特别好，并且根本不可重用。当我为这个应用程序添加更多功能时，我将需要一个更好设计的数据访问层，在我开始编写自己的应用程序之前，是否有人知道这种类型的设计模式有任何好的资源？另外，如果我需要转到内容提供者路线，我是否可以严格控制数据库事务？

Answer 1

我不认为你应该有一个问题，只是让你的内容提供者需要的功能位于你的直接数据库代码之上。内容提供者实际上只是一个访问结构化数据的抽象，而这些数据看起来非常像SQLite。 :)如果应用程序的各种内部部分直接访问与提供者相同的数据库，只要两者的代码很好地一起播放，就应该没问题。

我其实不是绝对的“你必须使用内容提供者”。如果您不需要内容提供商，请不要使用它;如果它更容易，就直接执行SQLite。如果您需要一个内容提供商与其他应用程序进行某种特定的交互，请随时为其编写一个内容提供程序，而不会让它成为支持应用程序在数据库内部执行的所有内容的复杂事情。如果这更容易，很好。这也使得您无意中将隐私数据从您的应用暴露给其他人的可能性大大降低。

Answer 2

不要在此引用我，但我敢肯定，内容提供者是一种抽象方式来提供数据提供给对象的方式。这样，您的对象可以与提供者进行通信，而不关心实现，即数据如何/在哪里存储。也许您可能希望提供一些其他方式来存储未来的数据，使用内容提供者范例将为您节省大量返工，因为它只是基于接口的通信。

我会在任何地方使用Android设计模式。说实话，现在看，我真的应该在我的项目中这样做。