使用DAAB 3.5 / 4.0的DAL设计

Question

I'm working on a .Net 3.5 web application.It has various modules say for example Customers,Orders,etc.... I need to a design Data Access Layer (DAL) for the same using Enterprise Library 4.0 (using Data Access Application block or DAAB) to connect to SQL Server 2005. Here is how i plan to go about it:

• Have an interface called "IDataService".It will have members like "ExecuteReader()","ExecuteScalar()","ExecuteNonQuery()", "AddParams",etc...basically, this interface will almost look like that of DAAB.

• Have a class called "DataService" which implements this interface.This class will act as a wrapper over DAAB and each of the method will use the corresponding method in DAAB internally.

• Have Business classes(or Data Containers) like Customer,Data, etc which will have properties mapping to their corresponding tables attributes in the database.

• Have DAL classes for each module like CustomerDataService, OrdersDataService, etc.Each of these classes will have constructor code in which I will instantiate DataService class as below: IDataService dataService= new DataService() Also, each of these classes will have methods like: GetCustomerDetails() AddCustomer() RemoveCustomer() UpdateOrder etc. These methods will internally use "dataService" object to make any operation on the database ExecuteReader,ExecuteNonQuery, etc

• Have a mapper class for each module like "CustomerMapper","OrderMapper",etc. These class will take datasource(for example IDataReader) as input and would fill in the data in the generic collection (List). And these mapper classes will be internally called by the corresponding Dataservice class to return the type-safe collection to the calling client.

• Have a helper class like DbHelper which will do tasks like "handling DBNull cases","storing stored procedure names",etc.

• DataService classes will be inturn used by the BusinessLogic layer classes...ie CustomerBusiness,OrdersBusiness,etc.

• Business Logic layer will return the collection to the presentation layer .

Does this design make sense?What are the advantages/disadvantages of this approach? The advantage I could think of this approach is that all DataService classes will alway program against the interface "IDataService" without needing to know how "DataService" class is implemented internally.So in the future,if i remove DAAB and use another API inside my DataService class, the client code need not change. Also,I can add any method in my IDataService interface which is not present in DAAB....for example BatchUpdate()...

Please correct me if i am wrong.

Answer 1

It looks like you are making it complicated than it should be. Maybe take one step at a time would help.

DAL: I don't see the benefits of having a wrapper over DAAB. IMO, DAAB is already a DAL wrapper. Wrapper over wrapper is counter productive. There should be only one DAL. That's the whole point of DAL.

ORM: For mapper class, perhaps you should consider using Entity Framework or NHibernate for ORM. Code your own ORM is tedious and hard to maintain when schema evolves.