In three tier architecture when BL class calls DAL to retrieve data from the DB we are having two options to get these data one is DataSet/DataTable and another one is DTOs (Data Transfer Objects). DTOs are classes which mapped to the DB tables. For example if Category table in Db having fields ID, Name and Description in this case DTO class will only have three properties named ID, Name and Description. DataSet also having two options one is typed Dataset and another one is untyped dataset. We will not discuss untyped dataset because it is having lots of drawbacks. In our case Dataset means typed Dataset. DataSets are easier to use because you get IntelliSense on field names, they provide built-in sorting and filtering facilities, they fully support data-binding for both WinForms and ASP.NET applications, and they have great integration with Visual Studio's IDE.
So, while returning data through DAL methods there are two options one is DataSet and another is collection of DTOs. Just search on “Live” or “Google” for something like "DataSet vs. DTO", "DataSet vs. custom collections" etc, and you will find a lot of opinions.
If we choose DataSets for passing data between the DAL and BL layers, we will need to access the data in the BL using ADO.NET methods. But if we choose DTO, accessing data in the BL in a more natural manner that has been customized for the particular data in question.
As per my view DataSets are clearly the best choice for smart-client (desktop) applications, but it is not true in case of scalable high-performance web sites. DataSets can easily support different strategies for handing concurrency, as the DataTable's rows store both the original value read from the data store, and the current value (which the user may have modified).
DataSets are having different disadvantage.
performance and scalability limitations: If we just need to pass a single row of data, we still need to create and pass an entire DataTable; and since it's an in-memory mini-database, it can be a fair amount of overhead. Every time the database schema changes a little, we have to rebuild the typed DataSet, which is harder than modifying a DTO class.
business rule validation: We can't easily add your custom business and validation logic to a DataSet, so we have a lot of ugly code to write to enforce all those business rules. We also have to write code for constraint checks and validation that must be performed to ensure that a value, or a record, is valid and meaningful within its context
If the DAL and BL are two separate layers, we can use these DTO collections between the DAL and BL. These DTO classes are very simple, as they typically just wrap the data retrieved from the DB, with a one-to-one relationship with the DB tables (or the DB views, which may join multiple tables), and without methods for inserting, updating, deleting, and retrieving the data. In this context they are just utilized as a container to hold data that is transported between layers.
I've seen DataSets used in some scalable applications but as per my views DTOs are still more flexible and elegant, and I generally prefer them over DataSets in web applications. But the use of DTOs will require us to spend a little extra time and effort to design and code the BLL layer in order to get these advantages.
Reference : ASP.NET 2.0 Website Programming: Problem - Design - Solution
Cheers!!!
Mahesh
maheshsingh21@hotmail.com