內容提供者與直接訪問數據庫（事務管理）

Question

我至少在紙面上了解內容提供者和直接訪問SQLite數據庫的基本區別。我有一個適用於我的應用程序的函數原型，目前它只是直接訪問數據庫。我真的沒有使用Content Provider模式的經驗，但我發現我需要與另一個應用程序共享一些數據。

我只會共享12個左右的表中的2個，所以我想知道是否應該完全重做數據層以遵循Content Provider模式，或只是通過Content Provider公開這些表爲了其他應用程序的緣故，仍然直接訪問主應用程序中的數據庫。

我與我的原型遇到的問題之一是我有一些相當複雜的交易，我寫的代碼讓我工作的設計不是特別好，並且根本不可重用。當我爲這個應用程序添加更多功能時，我將需要一個更好設計的數據訪問層，在我開始編寫自己的應用程序之前，是否有人知道這種類型的設計模式有任何好的資源？另外，如果我需要轉到內容提供者路線，我是否可以嚴格控制數據庫事務？

Answer 1

我不認爲你應該有一個問題，只是讓你的內容提供者需要的功能位於你的直接數據庫代碼之上。內容提供者實際上只是一個訪問結構化數據的抽象，而這些數據看起來非常像SQLite。 :)如果應用程序的各種內部部分直接訪問與提供者相同的數據庫，只要兩者的代碼很好地一起播放，就應該沒問題。

我其實不是絕對的「你必須使用內容提供者」。如果您不需要內容提供商，請不要使用它;如果它更容易，就直接執行SQLite。如果您需要一個內容提供商與其他應用程序進行某種特定的交互，請隨時爲其編寫一個內容提供程序，而不會讓它成爲支持應用程序在數據庫內部執行的所有內容的複雜事情。如果這更容易，很好。這也使得您無意中將隱私數據從您的應用暴露給其他人的可能性大大降低。

Answer 2

不要在此引用我，但我敢肯定，內容提供者是一種抽象方式來提供數據提供給對象的方式。這樣，您的對象可以與提供者進行通信，而不關心實現，即數據如何/在哪裏存儲。也許您可能希望提供一些其他方式來存儲未來的數據，使用內容提供者範例將爲您節省大量返工，因爲它只是基於接口的通信。

我會在任何地方使用Android設計模式。說實話，現在看，我真的應該在我的項目中這樣做。