Datasets, DAO's or DTO?

Importantly the DAAP from Ent Lib takes away a lot of the effort in writing the boiler-plate code to use data access storage layers. It also abstracts you away from knowing exactly which database you are using which means you can get closer to being independent of the actual storage mechanism. The original design target was to do all of this without slowing the performance by more than 5% compared to boilerplate code. It takes a minimum of effort to setup, though from the documentation you might think otherwise. The whole enterprise library works really well together to help you do all sorts of common tasks and is well worth a look, not just at the DAAP, though each block basically works on its own without the others (apart from the core blocks).

The DAAP is good for a plug-n-play library which you can use to quickly churn out your DAL code, filling either datasets or other objects in the process. As with all generalised methods it lacks some functionality, such as dealing silently with broken connections etc., but as it comes with the source code you can improve this to suit your needs if necessary.

Even a DataSet is loaded using a DataReader, that isn't necessarily the "heavy" bit. I would recommend getting hold of a copy of Lutz Roeder's Reflector and opening up the DataAdapter's Fill methods, and the SqlCommand objects ExecuteReader, ExecuteNonQuery, ExecuteScalar methods; they all use a datareader. I'm willing to bet that the slow part of filling a dataset or table with a dataadapter is initialising, and the fact that it also contains a lot of logic such as constraint checking. This in itself is something you can turn off by wrapping the dataAdapter.Fill() method with dataTable.BeginLoadData() and EndLoadData.

Serialisation is heavy for a dataset as well, both in performance and bulk. You can easily implement compression on your web services if clients accept it, and write clients to accept compression from web services, so even this might not matter to you.

You may not be serialising though, in which case there will be little difference in passing a DTO and a Dataset/table across tiers. As for databinding, I have never performed performance tests, so I don't know which is faster.

Personally I think what it comes down to is where you think your time constraints are going to be; programming or performance. In a properly layered enterprise application it will take time, but you shouldn't have a major problem, changing from datatables to DTOs. What you are essentially doing is choosing between two Enterprise Patterns for data handling (see Martin Fowlers book). In performance terms, you need to ask if it even matters. If you are only passing around a few datasets over a web service in a day, and your only clients are smart clients you write, then datasets are probably fine. If you are worried about performance, write tests that are specific to your environment and decide that way.

If you do go down the DTO route, I suggest writing a VS macro to help you create them. This is a really good starting point:
http://pluralsight.com/blogs/keith/archive/2006/01/08/17911.aspx