There has been a lot of debate on the subject of typed data sets and their use outside the Data Access Logic (DAL) layer. Some advocate that typed data sets provide so much functionality that it would be a waste to try to reproduce it with custom business entities. The following are some of the points made in favor of data sets:

They are auto-generated. You define a schema, press a button (sort of) and voilà.

There is no arguing there, typed datasets are not difficult to define and create. However, just because something is easy to do, it does mean it is all right to use everywhere.

They include functionality for handling the concurrency issues of optimistic locking.

Again, this is a great feature of (typed and non-typed) datasets and it would require some work for custom business entities to reproduce this behavior.

They are easy to sort and filter and binding controls against them is simple and native support exists.

Datasets are indeed easy to sort and filter, but is this functionality that you need in your business layer? Don't we all agree that representation of data should be separate from its definition (Model View Controller)? Just because you would like to see a customer's invoices in reverse date order on the screen, it doesn't mean that your invoice objects need to be sorted. If you were using Windows Forms you could use one of the great listview controls posted on Code Project that allow filtering, sorting, grouping and a bunch of other features as well. Now, I understand that ASP .NET controls cannot sort data like Windows Forms controls can. However, just because the controls do not have the functionality that they should we shouldn't be advocating that datasets are what should be used, but rather demand future controls to include the missing functionality and perhaps tie ourselves over with datasets for the time being.

They play nice with XML and they are easy to pass through web services.

I put "play nice with XML" and "easy to pass through web services" on the same point on purpose. This because a lot of people think that simply because something serialises into XML it immediately qualifies it to be used within Web Services. There are numerous posts on how advocating for a message driven model when using Web Services is a lost cause, but I think interoperability is something most developers still feel strongly about. This article explains why passing datasets through web services breaks interoperability. It also describes some work arounds, but as soon as you use them you lose all that great functionality of datasets.

They support relations.

Why would you need relations to be modeled within a single business entity? The usual example here is how an entity might represent data in both the Order and OrderDetails tables. Well, are Order Details important to the client of the business layer? Which bits are important? Is it just the items? If that is the case then the Order can have a collection of Product objects associated with it. There will be exceptions of course, but in my opinion if you have business entities that represent tables of data and relations rather than single rows then your design is wrong.

Conclusion

I agree that datasets have a lot of functionality built into them, which would be nice to leverage. However, I don't think the solution is to expose datasets as business entities. They have functionality that is usually not required and there is no arguing that polluting an interface is bad. They have functionality that is dangerous. How are you going to stop a client from doing AcceptChanges before data is actually persisted? Being able to access values using indexers (e.g. DataSet.Tables["Customers"] or DataSet.Tables[0]) prevents bugs from being caught at compile time.

Some conclude that the advantages of using datasets as business entities outweigh the disadvantages so they go ahead and use them. Others prefer to do quite a bit of extra work to keep their design clean so they implement business entities from scratch. In the following few days I will post what I believe to be a satisfying compromise between the two. A design that can leverage the useful functionality of datasets, but at the same time keeps the interface clean and simple.

Some other articles and posts on the subject

Datasets vs Custom Entities by Barry Gervin

DataSets II by Andres Aguiar
Oops! Typed Datasets ARE scalable! by Roy Osherove