良好的移動數據庫邏輯應該如何構建？

到目前爲止，我已經制作了數十個使用數據庫的應用程序。我沒有深入研究數據庫邏輯以及如何構建它，但是儘可能簡單並遵守規則。良好的移動數據庫邏輯應該如何構建？

例如，我的數據庫邏輯通常由一個擴展爲SQLiteOpenHelper的數據庫類組成。然後我爲每個表製作CRUD方法。每次我必須處理一個數據庫時，我會做一個特殊的AsyncTask，並在其中處理數據庫。就是這樣。

與一些開發人員交談時，我被告知我的邏輯結構應該更復雜，更多的OOP。我試着在網上找到樣本，但都是針對解釋如何處理數據庫的。我甚至回顧了一些開源項目，但他們的邏輯與我的相似。

你能幫我嗎？我應該如何使數據庫邏輯更多的OOP？我想他們提到我應該能夠在將來重用這個邏輯，只改變處理特定數據庫及其表格的最低部分。

來源

2013-08-30 sandalone

這是一個稍微主觀的問題，所以這裏是一個主觀的答案。沒有一個正確的方法來做到這一點，我只能談論我個人喜歡如何工作（大項目版本，小項目有另一個故事）。對於你或你的團隊來說可能會有所不同。

作爲參考，我主要工作是敏捷的，例如，要求可以改變。代碼中的API可以改變（並且經常這樣做）。這當然會影響我認爲有用的東西以及我認爲對我的個人工作無用的東西。

另外，我喜歡在沒有大框架的情況下工作，儘可能地。這就是爲什麼在下面解釋的模型中沒有框架。

我把數據庫的工作爲三個部分一起工作：（相當長的一段similatities與MVC pattern）

實際數據庫後端（可以執行SQL）。可以包含用於跨平臺工作的自己的代碼。
存儲分類，負責存儲特定於應用程序的信息。每條信息都可以從存儲類中讀取和設置（例如：interface AddressBook提供對類型爲interface Contact的元素的訪問，這些元素具有某些東西的getter和setter，實現將其轉換爲後端中的單個表）。
應用程序代碼，它執行實際工作並根據應用程序進一步拆分（例如：提供地址簿GUI的東西等）。

爲什麼我這樣分裂？那麼，一個原因就是輕鬆切換到新的存儲或數據庫後端。如果我發現在重組表格時可能會有更高的性能，以便滿足新的要求，我會更新存儲類別。這樣我就不必觸摸任何應用程序邏輯（例如：爲電子郵件地址添加一個1：n表格到地址簿中。新表格及其關係不會影響應用程序中的任何代碼，它可以收回電子郵件列表來自聯繫人的地址，並輕鬆地添加或刪除它們）。

另一個原因是應用程序代碼很容易閱讀（因爲它由應用程序代碼組成），而存儲代碼也很容易閱讀（因爲它只需要存儲，緩存和類似的東西）。

第三個原因是，如果我希望添加另一個存儲機制（例如，當切換到具有內置數據庫後端的平臺或添加可選Web服務時） - 我可以使用所有OOP機制三層;例如，多個存儲可以在同一個應用程序中共存，以便用戶可以選擇本地存儲數據（存儲與數據庫後端）或雲中。

我希望這個答案能夠讓你對應用程序的數據庫相關部分中的OOP的一些可能性有一點了解。再次，這是而不是這是一個正確的方法來做到這一點，只有一個我發現工作得很好。

來源

2013-08-30 18:23:40 dst