Monday, August 22, 2005

DataAccess layer with Dataset

There have been few approaches that we used to follow while developing the Data Access Layer

1) Create Entity Classes and directly call Database Code to access the data
2) Introduce a DB independent data access Layer which in turn call respective Database Code to access the data. This also involves creating command and parameters, connections on higher level.

But the common thing is that there isnt much abstraction in between business and the data acces layer and we have to write too much lines of code for the CRUD operations. Also everytime we make a new application there is some dependencies created.

I personally believe in this approach which i am mentioning below. I am just presenting the idea for which implementation is upon the followers.

More Exhaustive Use of dataset

First thing an application should follow is to use Dataset as a medium of data transfer. Every layer should have supportive methods to get/set the data in Dataset form. This doesnt mean that we should not make Business Layer entities and abstracted methods. The only thing is to keep this approach in parallel to your normal archtectural design.

For each entity you should have a DataTable mapped to database table and for each conceptual module you should have a DataSet (my recommendation is to use a Typed Dataset). So we have a Dataset which contain several tables of the related module.

How To make things Simple and Generic

Now the DataAcces Layer must solely should work on Dataset. As we know that Dataset is the projection of a relational database, so it contains all those elements required for a Database operation.

Question is how it simplifies things?
Let us assume that each entity have to be saved in database and we have a datatable for each entity. Now what the only thing a programmer has to do is to check the rowstate of every row (Added,Modifed,Deleted) and do the appropiate operation on it. This will involve traversing all the DataTables in the DataSet and all the rows in the DataTable. This will also help to apply transactions more easily as the whole operation is done from a single entry point i.e save method.

e.g We have a order module. Order has a Dataset which contain order detail and its product. Assume we want to save the Order to database. Now your save function will take a dataset input which will contain all the details of the order. It will traverse each tables (OrderDetail,OrderProduct) and each row of these tables. For each row we will check the status of the row.
If it is Added, we will call insert procedure for the entity
If it is Updated, we will call update procedure for the entity
same as for delete.

If you understand me correctly what this mean is that our Data Access Layer will only contain one save method for the whole application. As this save method is enough capable for doing all the saving operations to the database.

Now questioning its Genericity, this approach is using Dataset as it main data transfer medium and dataset is a part of .Net framework. Dataset itself contain enough information to cater all types of database operations. So, it is clear enough to use this Data Access Layer in any of your application provided application should be based upon Dataset.

The amount of code will be reduced to only one function for each operation which will make it simple and highly manageable.


Post a Comment

<< Home