ASP.NET MVC模型接口

看來我現在已經解決了我所有的LINQ問題，但我並沒有在開發一個實際的模型。事情是這樣的，我不想希望被綁在一個單一的技術，我想有自由實施不同的數據訪問技術，並工作到一個單一的接口。ASP.NET MVC模型接口

現在，我從來沒有這樣做過，但基於我的面向對象的知識和經驗，我想出類似如下的想法：

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Text; 
using System.Data.Linq; 

namespace Intranet.Data.Accounts 
{ 
    interface IContractsControl 
    { 
    ContractsControlViewData GetContracts(System.Nullable<int> contractTypeID, 
            System.Nullable<int> responsibilityID, 
            string expenseType, 
            System.Nullable<int> supplierID, 
            string businessID); 

    ContractsControlViewData GetContract(int contractID); 
    } 
}

我已經得到了這是如何的幾個問題應該管用。

接口在哪裏生活，考慮到我正在使用由Phil Haack開發的區域庫。現在我已經在根級創建了一個名爲「Data」的文件夾（如您從名稱空間中看到的那樣）。
我們的存儲過程具有虛假名稱，因爲它們被集中到一個數據庫中，如果我正在使用對象，我可以轉而使用基於對象的解決方案來訪問sprocs。在我的數據訪問庫中的名稱是否必須反映這種情況下的存儲過程？
使用這樣的庫將允許我在我的控制器中執行Accounts.GetContracts()。這是明智的嗎？
這種方法是否有任何設計建議？即命名方案。
實際實施應該在哪裏生活？在與界面相同的文件夾中？

想法是，如果我們曾經溝通過LINQ，那麼我們可以使用不同的數據訪問技術（實體框架，普通SQL等）。我很樂意聽到那些更有經驗的人的評論/批評/評價。

來源

2009-06-23 Kezzer

有關信息，您可能會發現「int？」一個更快的方式說「System.Nullable 」... – 2009-06-23 09:34:59

乾杯馬克，我曾經想過這個，因爲我看到兩個都在使用。我更喜歡System.Nullable ，因爲我可以清楚地看到它是可空的。我常常瀏覽一下「？」做法。 – Kezzer 2009-06-23 09:36:04

您的方法看起來很像存儲庫模式，受到許多ASP.NET MVC教程編寫者的讚揚...... =）這是一個tutorial，它描述瞭如何使現有的應用程序鬆耦合，以及其中的一件事是如何在ASP.NET MVC中實現存儲庫模式的。

來源

2009-06-23 09:39:01

IMultipleResults對我來說就像一個拇指疼痛。它並不完全公佈真正的返回類型給調用者。

如果您想要真正的存儲庫抽象，您可以有一個單獨的Contract類型，與您的ORM工具無關，並返回這些數組/列表。一些框架（NHibernate，如果你足夠努力的話，LINQ到SQL，4.0版本的EF）支持POCO使用，允許你通過ORM工具使用簡單的（非ORM）對象。所以，我的偏好是：

基於接口的存儲庫，返回數組/列表/的等等...
...混凝土POCO類型

接口數據類型的額外抽象會對一些數據綁定設置造成嚴重破壞（例如，它無法創建新記錄）。

來源

2009-06-23 09:38:48

至於你的第一句話Marc，你完全正確，我不知道爲什麼我這樣做是對你誠實的，因爲我正在使用數據類型來表示多個結果集。我只是編輯我的帖子來反映這一點。 – Kezzer 2009-06-23 09:40:26

ASP.NET MVC模型接口

回答

相關問題