DAL設計使用DAAB 3.5/4.0

Question

我正在一個.net 3.5網站application.It有各種模塊比方說客戶，訂單等....我需要設計的數據訪問層（DAL）的同樣使用Enterprise Library 4.0（使用數據訪問應用程序塊或DAAB）連接到SQL Server 2005.下面是我打算如何去做的：

•有一個名爲「IDataService」的接口。 「的ExecuteReader（）」， 「的ExecuteScalar（）」， 「的ExecuteNonQuery（）」， 「AddParams」，等等...基本上，這個接口將幾乎看起來像DAAB的。

•有一個名爲「DataService」的類來實現此接口。該類將用作DAAB的包裝，並且每個方法都將在DAAB內部使用相應的方法。

•擁有像客戶，數據等業務類（或數據容器），它們的屬性將映射到數據庫中相應的表屬性。

•對於每個模塊（如CustomerDataService，OrdersDataService等）都有DAL類。每個類都有構造函數代碼，我將在其中實例化DataService類，如下所示：IDataService dataService = new DataService（）此外，每個類都將具有如下方法：GetCustomerDetails（）AddCustomer（）RemoveCustomer（）UpdateOrder等。這些方法將內部使用「dataService」對象對數據庫ExecuteReader，ExecuteNonQuery等進行任何操作。

•爲每個模塊都有一個映射器類「CustomerMapper」， 「OrderMapper」 等。這些類將採用數據源（例如IDataReader）作爲輸入，並將填入泛型集合（List）中的數據。這些映射器類將由相應的Dataservice類在內部調用，以將類型安全的集合返回給調用客戶端。

•有一個像DbHelper這樣的助手類，它可以完成「處理DBNull案例」，「存儲存儲過程名稱」等任務。

•DataService類將由BusinessLogic層類使用，即CustomerBusiness，OrdersBusiness等。

•業務邏輯層將集合返回到表現層。

這是否設計合理？什麼是這種方法的優點/缺點是什麼？我能想到這種方法的好處是，所有DataService類總是支持程序對接口「IDataService」，而不需要知道如何「的DataService」類在未來實現internally.So，如果我刪除DAAB並使用另一個API裏面我DataService類，客戶端代碼不需要改變。 另外，我可以添加任何方法在我的IDataService接口，這是不存在的DAAB ....例如BatchUpdate（）...

請糾正我，如果我錯了。

Answer 1

它看起來像您這樣的複雜它比它應該是。也許一次一步就會有所幫助。

DAL： 我沒有看到DAAB封裝的好處。 IMO，DAAB已經是DAL包裝。包裝器上的包裝是反生產的。應該只有一個DAL。這是DAL的重點。

ORM： 對於映射類，也許你應該考慮使用實體框架或NHibernate for ORM。在架構演變時，編寫自己的ORM非常乏味且難以維護。