N-Tier development revisited

Discussion forums on the web are full of .Net N-tier questions, especially on approaches for achieving loosely coupled layers and lightweight data passing mechanisms. Is it ok to pass a DataSet or DataTable? Should I use Custom classes? This article by Imar Spaanjaars is one of the better ones I have seen on the topic:

http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=416

He describes the pros/cons of the different approaches. He is a fan of pulling the "data only bit" out of your business layer objects and putting them into separate "business objects" (only containing data). This aids passing of data between tiers and project referencing.

Question though - does pulling the data out of your business layer objects go against pure OO principles? "An object should consist of the data and operations allowed on that data" etc. Abstract data types (ADTs), encapsulation etc bla bla...

Also, I don't like the BO (business object) terminology as it is used, as this implies more than just data... I'd prefer something like CustomerBDO (business data object) or even CustomerEntity. You could then perhaps lose the "*Manager" suffix notation he has adopted for the business logic layer.

Regardless of these points though, I think custom classes are the correct way forward for "passing data", and datatables etc should be saved for when the types of the results are dynamic, e.g. "adhoc reporting" result sets.