There are sound technical reasons not to use DataSets in ASP.NET applications due to their stateful nature. These reasons are explained by Frans Bouma in his blog at http://weblogs.asp.net/fbouma/archive/2003/05/13/6966.aspx. I have experienced other reasons not to use DataSets as a business layer.
The entity-relationship model (the way data is organised in database) rarely corresponds so perfectly (see the video mentioned above) to the way you are going to present it. You will need to go through various transformations, for example:
- You may have an invoice which is constituted of items and you need to present the invoice total which is actually the total of all item amounts. This total may also need to be presented in several currencies.
- You may have an N-N relationship between messages and contacts in your database, but you need to display a message with a To, Cc and Bcc fields which are separated lists of email addresses.
- You need to store UTC dates which will have to be converted using the time zone defined in your user’s profile;
- You need to store country codes which will have to be mapped to localized country names;
- You need to store a document status as a byte like 0, 1 and 2, which will have to be mapped to an enumerated value like “draft”, “approved” and “rejected”.
So what should we do?
- Implement your data access layer (DAL) as stored procedures handling create, read, update and delete (CRUD) operations;
- Implement a business logic layer (BLL) in C# or VB.NET calling stored procedures using data readers and commands, which will achieve much better performances.
- You only use datasets in rapid application development (RAD) scenarios, or when
- You have no other choice, for example when a component that you need (otherwise you would spend hours reinventing the wheel) requires datasets.