通過改變模式針對數據庫開發應用程序

Question

我正在開發基本上是基於Web的報告工具的ASP.NET MVC應用程序。我從我的報告中提取的數據庫仍在開發中，即其模式可能會更改，但是如果這樣做，它應該只會最小程度地改變。

與其等待數據庫模式變爲具體，我決定現在可以將我的數據模型定義爲POCO，並使用存儲庫接口來檢索數據（以及Ninject for IoC）。這樣，我現在可以使用測試數據構建我的報告視圖模型，然後再實施我的存儲庫以使用真實數據庫，理想情況下無需更改我的模型 - >視圖 - 模型映射。

第一個問題是關於術語：因爲這是一個報告應用程序，所以我的數據庫交互是隻讀的。存儲庫是在這裏使用的正確術語嗎？

第二個問題是：這是一個體面的方式去關於這個項目？如果您的的創建了一個報告應用程序，其中您的備份數據庫架構不具體，您將如何執行此操作？

Answer 1

我的數據庫交互是隻讀的。存儲庫是在這裏使用的正確術語嗎？

不是。存儲庫本質上是一個在底層數據提供者和任何代碼使用它之間操作的外觀，通常通過接口公開所有可用的操作。它通常包裝底層提供者（EF，NHibernate等），因此消費代碼不知道如何實現持久性機制。

您希望它是「只讀」的事實是一個實施問題。如果你不需要做任何寫操作，我甚至不會打擾ORM。這太過分了。只需使用存儲過程，如果你喜歡，可以用一個簡單的組件如Massive或Dapper來包裝它。然後，您可以通過一個非常簡單的存儲庫公開這些存儲過程，只是公開這些查詢，而沒有其他。以防萬一你想切換到其他經典的ADO.NET。

使用存儲過程的有一個額外的好處，你可以在存儲過程的假結果。例如，不要讓它進入實際的表格，而應該使結果集僞裝成所期望的結果。

然後當模式準備就緒時，更新SPROC並且你的測試應該都仍然通過，假設你正確地「僞造」了。當然，如果需要新的字段，可能需要更改一些代碼。但是在這裏使用SPROC意味着你的查詢將會超快（ORM膨脹沒有問題，接近金屬），並且它也有助於你的場景。

我可能會受到「存儲過程是史前」追隨者的攻擊，但這就是我在你的場景中所做的。