如何決定直接訪問數據庫和內容提供者？

我正在編寫一個由業務邏輯和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

回答