DAL design question

Question

I need to design a Data access layer DAL .Net Enterprise library version 3.5 Data access application block (DAAB) In my application,I've various logical modules like Registration, billing, order management, user management,etc Am using C# business entities to map the module objects to database tables and then return the List collection to the client.

I would like to design my DAL in such a way that if tomorrow we decide to use some other data access framework we should have minimal code change. Given this, how do i design my class structure? I thought I would have a class DbManagerBase which would be a wrapper over existing .net DAAB This class DbManagerBase would implement an interface called IDbManagerBase which would have public methods like ExecuteReader, ExecuteNonQuery, etc.

The client class ie. RegistrationDAL,UserManagermentDAL would have the following code inside each of its methods: IDbManagerBase obj= new DbManagerBase() obj.ExecuteReader(myStoredProcName) . . . is this a good OOPS design?may i know any better approach please?or do i need to use inheritance here? Can i have all the methods in DbManagerBase class and RegistrationDAL,UserManagermentDAL classes as static?I guess,if i've methods as static then the above interface code wont make any sense...right???

Answer 1

To truly abstract the DAL I'd use the repository pattern.

Answer 2

To answer a few of the questions:

Can i have all the methods in DbManagerBase class and RegistrationDAL,UserManagermentDAL classes as static?

I would probably go with a non-static approach cause it gives the flexibility to better control instantiation of the DALs (eg. you could create instances of them from a factory), also it will allow you to have two DALs in place that are talking to different DBs in a cleaner way. Also you will not need to create an instance of the DbManagerBase in every object since it would be an instance member.

Regarding IDbManagerBase having ExecuteReader, ExecuteNonQuery and obj.ExecuteReader(myStoredProcName)

I would be careful about baking the knowledge about database specific concepts in too many places. Keep in mind some DBs to not support stored procedures.

Another point is that before I went about implementing a DAL of sorts I would be sure to read through some code in other open source DALs like NHibernate or Subsonic. It is completely possible they would solve your business problem and reduce your dev time significantly.

If you are looking for a small example of a layered DAL architecture there is my little project on github (it is very basic but shows how you can build interfaces to support a lot of esoteric databases)