I'm thinking through data access for an ASP.NET application. Coming from a company that uses a lot of Windows applications with Client Data sets there is a natural dendancy towards a DataSet approach for dealing with data.
I'm more keen on a Business Object approach and I don't like the idea of caching a DataSet in the session then applying an update.
Does anyone have any experience / help to pass on about the pros and cons of both approaches?
If you're going to follow Microsoft's direction, then the trend is definitely towards LINQ (ORM) vs. DataSets. When DataSets came into being (ASP.NET 1.0), LINQ wasn't even possible. With LINQ you get type-safety and build-in functions to Create / Update / Delete from the database.
Microsoft has even tried to make the transition easier through LINQ to DataSet.
DataSets can be incredibly inefficient compared even to other ADO.NET objects like DataReaders. I would suggest going towards the BO/ORM route based off what you are saying.
You are smart to be thinking of designing a Data Layer in your app. In an ASP.NET application this will help you standardize and pretty dramatically simplify your data access. You will need to learn how to create and use ObjectDataSources but this is quite straightforward.
The other advantage of a data access layer (built using a separate project/DLL) is that it makes Unit testing much simpler. I'd also encourage you to build a Business Layer to do much of the processing of data (the business layer, for example, would be responsible for pulling ObjectDataSources from the DAL to hand to the UI code). Not only does this let you encapsulate your business logic, it improves the testability of the code as well.
You do not want to be caching DataSets (or DAL objects, for that matter) in the session! You will build a Web app so that record modifications work through a Unique ID (or other primary key spec) and feed changes directly to the DAL as they are made. If you were to cache everything you would dramatically reduce the scalability of your app.
Update: Others on this thread are promoting the idea of using ORMs. I would be careful about adopting a full-blown ORM for reasons that I have previously outlined here and here. I do agree, though, that it would be wise to avoid DataSets. In my own work, I make extensive use of DataReaders to fill my ObjectDataSources (which is trivial due to the design of my DAL) and find it to be very efficient.
We're about to do a big update to an existing asp app that used DataSet objects heavily; although I am not looking forward to the pain, I am going to insist on going down the BO route. Just the thought of trying to make datasets work now causes me to break out in a sweat.
I think we are going to go down the LINQ route and use lightweight entity objects.
The company where I work makes heavy use of DataSets as well while there is a business layer as well. BL mainly loads datasets from the DB.
I personally dislike this approach. There is also a practice of direct modifying the datasets after load/before save to meet some immediate needs here and there. To me it really violates the idea of business objects but it's how it is done.
ORM frameworks can really save you a great deal of time, especially in enterprise applications with lots of views with similar buttons and operations.
But it's also easy to lose control. Since that point it will slowly be turning into a mess.
Both options are good when used in right cases. Just don't mix them. Decide to do it one way and follow it.
Mark Brittingham's answer is accurate for two tier applications. But what if I want to use a service tier. DataSets are serializable. Typed DataSets save time over hand coding your own objects. Typed DataSets are extendable. Linq to Entities has performace issues, Linq to SQL is now dead. Linq to DataSet will always be an option.
I will use Typed DataSets and a multi-layered architecture to save time and organize code. I've tried hand coded BOs and the extra time and maintenance time is not worth it.