ASP.NET數據訪問層的設計決策

我有一套靜態數據庫訪問層類，可以對車輛，經銷商和大量跟蹤記錄進行CRUD操作。這些對象在內存消耗方面可以相當大，因爲記錄的音符等等。我們稱這組類爲「A」。ASP.NET數據訪問層的設計決策

另外，我還有另一個名爲Lookups的靜態類，它爲了填充DropDownLists而執行只讀操作。返回非常非常精細的對象（只是一個ID和一個文本字段） - 我們稱之爲「B」類

類「B」中的方法從與集合「A」中的方法相同的表中讀取。

B中的部分代碼看起來與「A」中的代碼相似，只是返回的是較小的對象。

我違反了B中的DRY原則，但僅僅是因爲我不想爲了填充下拉列表而返回大對象。我希望這個系統具有可擴展性，以便在RAM上輕鬆使用。但我不禁想到可能有更好的方法，設計明智。

你會推薦什麼？

對於下一個項目，我將使用實體框架，但這是老派的ADO.NET手動編寫的SqlConnection和SqlCommand對象。

來源

2013-05-30 user1154016

我想你應該爲你的業務邏輯的每個實體都有一個存儲庫。就像這樣：

// dealing only with Vehicle operations 
public interface IVehicleReposity { 
    // Operations.. 
} 

public class VehicleReposity: IVehicleReposity { 
    // Impementiong operations and 
    // calling your static methods 
}

這將允許您隨時更改您的業務邏輯。正如你將能夠稱之爲靜態方法，實體框架或Nhibernate，如果你想要有一天..

在這種情況下，你不會重複自己，你將能夠在依賴注入easlly 。

來源

2013-05-30 10:52:49 Mata

嗨馬塔，我目前有VehicleDA，DealerDA和HireDA類，其中每個處理各自實體的CRUD操作。 – user1154016

我打算加上DA = Data Access。另外，我還有一個LookupDA，可以從與這些對象相同的數據庫表中讀取數據。因爲LookupDA從相同的表中讀取，這意味着有一些重複的代碼。這是DRY違規，但我認爲這是最有效的內存。然而，我正在與自己對抗，認爲某處有氣味 – user1154016

ASP.NET數據訪問層的設計決策

回答

相關問題