Last large app was built using .NET 2.0 and analyzing existing ORM solutions we made a decision to use bltoolkit.net
This choice was maid because this project was free and not so big and complicated as others so we changed it a bit to fit our requirements.
The biggest question was whether we should use DTOs or not.
After some performance tests we realized that only ADO.NET data sets can be serialized over the network with the minimal traffic. So we built our own .net remoting channel to convert our objects (data entities) to datasets and back. Another solution was
to use typed data sets but as for me it looks to complicated because you have the as result same dataset with some properties and methods inside which gives you the possibility to work with it like with object. I prefer something more cleaner.
For other projects i used the same data access framework (of course with our own changes) because a lot of peoples in other teams already had some experience with.
Relating data access question: my opinion is that we have to separate data entities and business objects. Data Access Layer must deal only with data entities. Some middle level business logic must know how to validate business objects and convert it to/from
the data entities. As for me the system with this type of separation can be really scalable.
In general i know that a lot of architects agrees that the best practice is to change the objects between layers because it gives you the possibility to have different layer specific logic inside this objects and do not share it with other layers. (ex. Remoting
So i'd like to see in p&p data access guidance some chapter with recommendations about DTOs and object exchanges between layers.
In my new project i'm going to use ADO.NET Entity Framework.