每個表格或每個功能部分一個存儲庫？

我正在使用ASP.NET MVC 2和C＃與實體框架4.0來編寫規範化的SQL Server數據庫。我的數據庫結構的一部分包含一個與包含驅動程序，汽車，引擎，底盤等子表有關的外鍵條目表。每個表格或每個功能部分一個存儲庫？

我正在關注Nerd晚餐教程，該教程爲晚餐設置了一個存儲庫，足夠。我會爲司機做一個，爲發動機做一個，還是爲汽車做一個等等，還是爲一個參賽作品做一個大的作品？

這是哪類工作的最佳做法？我仍然對這種編碼方法不熟悉。

2010-06-06 Ian Roke

你想要完成什麼？什麼教程（添加鏈接）？ – tsinik 2010-06-06 14:45:41

我目前正在創建存儲庫類的第3部分。該網址是http://nerddinnerbook.s3.amazonaws.com/Part3.htm。 – 2010-06-06 14:50:28

我想這確實沒有單一的「最佳實踐」 - 這取決於您的編碼風格和您的應用程序的要求。你絕對可以爲你的系統中的每個實體類型創建一個存儲庫 - 這將工作得很好。在這裏，我可能至少會考慮擁有一個驅動程序存儲庫，可能還有第二個用於汽車，發動機和底盤的存儲庫（因爲這些都是在相同的專業領域 - 它們是相互關聯的，它們是相互關聯的「永遠在一起）。但是：當然，如果汽車，發動機和底盤的單一存儲庫過於臃腫，您可能會考慮將其分成三個獨立的存儲庫。

我會嘗試在存儲庫數量之間找到一個平衡點 - 嘗試將邏輯上屬於的東西組合在一起 - 以及這些存儲庫上的方法數量。五，十種方法是可以的 - 如果你正在談論20,30或50種方法，你的存儲庫可能太大而笨拙。

這絕對是一個架構決定，正因爲如此，他們並不是真正的很多事實來指導你 - 它更多的是「直覺」和經驗。如果你還沒有那種必要的經驗 - 用一種方法去使用它，當你完成時 - 用批判的眼光再次看看它，看看：它有什麼用？那麼它不起作用呢？然後在您的下一個項目中嘗試其他方法，並在項目結束時對其有效性提出質疑。活到老，學到老！

來源

2010-06-06 16:34:26

有史以來最好的建議！ – drizzie 2015-04-07 18:06:54

我對每個實體都使用通用（參數化）存儲庫。該存儲庫包含基本的CRUD功能。在上面我有服務爲每個功能。每個服務都實例化所需的存儲庫。 ObjectContext對於所有這些都是通用的，每個請求都有一個。這是我的存儲庫接口：

public interface IRepository<T> 
{ 
    //Retrieves list of items in table 
    IQueryable<T> List(); 
    IQueryable<T> List(params string[] includes); 

    //Creates from detached item 
    void Create(T item); 
    void Delete(int id); 
    T Get(int id); 
    T Get(int id, params string[] includes); 
    void SaveChanges(); 
}

我也有通用的實現，這很長，但容易實現。您不必爲每種類型創建存儲庫類，只需實例化Repository<Type>。

來源

2010-06-06 17:12:19 LukLed

個人而言，我覺得最好爲每個表格創建一個單獨的存儲庫。

然後我創建了一個services layer，其中在一個班級中，我將運行所有命令以執行特定操作（例如，將現有的駕駛員的車改爲新添加的車）。如果我需要完成的操作包含多個相互關聯的對象，那麼服務層就是我要調用多個存儲庫的位置。

我盡我所能讓我的存儲庫儘可能地「啞」，並將所有「智能」的東西放在服務層。額外的services圖層也有助於避免我的控制器膨脹。

來源

2010-06-06 20:12:40 Omar

我喜歡這種方法，但是我的團隊中的另一位開發人員提到，如果您的服務層必須進行4-5個表呼叫才能將所有需要的數據組合在一起，那麼可能會出現性能問題。這是一個必要的罪惡，還是有一種策略來緩解這種情況？ – 2017-08-17 13:50:14

這是一個很好的觀點，當JOIN變得更有意義時呢？您的服務層將比在數據庫上使用JOIN慢得多（一般情況下）...？ – 2017-11-08 16:37:12

你指出的是我提到的戰略確實崩潰了。在這一點上，創建一個函數特定的存儲庫可能是有意義的。這並不是說你必須擺脫每個表的一個存儲庫，你可以同時做兩個。 – Omar 2017-11-08 16:40:21

我通常採取數據庫的圖表，並圍繞我consisder一個更大的單位或系統畫圓圈。

這讓我在商店裏看到類似「ProductSystem」，「OrderSystem」，「UserSystem」，「PaymentSystem」的東西。

如果系統太大，我將它們分開。

如果系統太少，我不在意：無論如何，一切都會增長。

如果某件事屬於某種方式對2個系統，我選擇1並且不再改變它，即使第二天決定接縫錯了：我知道當我想再次改變它時，那一天會到來。

來源

2010-06-07 09:14:02

每個表格或每個功能部分一個存儲庫？

回答

相關問題