O/R Mappers
Frans , Mats and Paul are blogging about O/R mappers.
The problem with OR mappers is that you are still coding your Data Access Layer, but instead of using SQL, you are using the OR syntax. If you use an OR mapper in your ASP.NET page, you'll be violating the 'do not add data access code to your ASP.NET page'. You are not building your applications in layers.
If you use DataSets and a class that knows how to load it, persist it, etc, you have a much better architecture. If you have a layered approach in that persistence layer, you can change the way your application talks with the data source without changing your application code.
For example, you can change your app from using a '2-tier' architecture and talk directly to the data source, to make it talk to a webservices layer. You can add a layer that provides online/offline support. You can host your data access components in Enterprise Services. You can provide caching. All without a single change in your application code.
You can acomplish that with OR mappers but you need the OR mapper provider to do it. If it does not support it, you are usually stuck.
With a OR mapper you are coupling your data with your architecture. With a message-based approach using DataSets, you are not. So, it's OK to use a OR mapper to load a DataSet ;).
Update:
OK, I think I should refine it ;).
If your entity objects are [Serializable] then you are probably OK if you use a O-R mapper, as you can find a way to be architecture-independent, even if it could require to think about it in advance. If your objects must extend from a MarshalByRefObject (or a subclass, i.e. ContextBoundObject) then chances are that you are in trouble.