How much info do you really want? I'll preface my answer by saying that I've bought the book, which has been invaluable, as has this site.

Where I find the most work is having to deal with multiple database systems. Cross platform is still about as hard to do now as it has ever been. For trivial cases it's not bad, but any sort of real world product, it's still annoyingly difficult.

I'm deriving from strongly typed datasets in an abstraction layer - business layer really - in order to mask this complexity from the rest of my user code.

I'm working to not expose any native ADO.NET objects to my user code, and it's still (nearly as) painful and error prone as back in Windows 3.11/ODBC days...

Dare I say "it depends"? Sometimes COM+ is needed (usually not). Standard db transactions are more commonly a better solution due to overhead of COM+. Sometimes Typed Datasets get the job done very well, but more often the case seems that a dataset is just too limiting, too generic, and too costly. Regarding BOs vs messages, that's like apples and oranges to me... BOs handle complex logic, integrity and validation before delegating actual DML to a seperate DAL, whereas messages only make sense outside of the entire application domain and other rare situations (queueable atomic operations). Generally speaking though, I usually end up with a simplified programming model that handles (non COM+) transactions and connection establishment/cleanup in a base abstract class, underneath a generated DAL class that provides simple metadata-driven entity DML mapping, those two peices comprising a DAL. I take care to isolate database dependance (references to SqlClient/OracleClient) in the DAL to protect high layers from it. On top of this DAL, the BO classes add domain logic. In this scenario, I find that using DataSets/DataAdapters only adds more complexity to the solution, and makes it prone to loose-typing issues. Typed Datasets help a little, but they still force you to always work with data in tabular sets. If all you want is a single row - you still have to make a whole dang dataset (which causes headaches with distributed systems when the BinaryFormatter does it's magic). I also try to avoid COM+ unless I have significant need for it (Interop or DTC).

Data access with .NET is not that hard.

COM+ transactional stuff is an incredible pain to deploy and manage.

Dude, this text box makes me feel like a gynaecologist. I am trying to fix a bigger problem thru a very small hole. It's barely 10 characters wide. CANUFIXIT please :)

I just put some thoughts together on typed datasets recently in an article on aspnetPRO (http://www.aspnetpro.com/features/2005/03/asp200503hg_f/asp200503hg_f.asp - registration required though) that might be on use in this discussion (I hope so :->).

I used TDS's quite a bit last year and just joined a project at our client that is BO/datareader-based. I'm quite a fan of TDS's when they are used appropriately. They give a lot of out-of-the box functionality and can be extended nicely with Attributes too. They are not lightweight though and so can be easily abused.

grr "Attributes" = "Annotations". Need another cup of coffee...