The Death of Inherited Typed DataSets?

I’ve spent most of the last week in Redmond seeing some new stuff and meeting up with old friends.  While I was here I scheduled some time to sit down with Steve Lasker of the Visual Basic/Visual Studio Team.  His team in in charge of the Typed DataSet in Whidbey.

I met with him to discuss the inheritability of Typed DataSets for business logic.  If you’ve been reading much of what I have written in the last three years, you probably know how long I’ve advocated the use of Typed DataSets as a replacement for Business Objects.  Alas, I’ve finally been convinced by Steve that they never intended Typed DataSets to be inherited.

In our discussion, he suggested using Typed DataSets and registering for events to do simple business logic is where they envisioned to be the limit of that use.  They seem to be convinced that the DataSet can be too heavy for certain situations.  They’ve spent a lot of time in the Whidbey bits to make object binding work much better than in the 1.x Framework.

It still seems to me that the inheritant strength of tool-driven data access, built-in storage of current/original data in the DataRow/Table, the implicit ‘dirty’ flags in DataSets, the DiffGram story in Whidbey and the xsd/Web Services/DataSet crossroads means there is still a strong DataSet story.

The problem as I see it is still that building deep object models is a lot of work.  Maintaining these object models is a lot of work.  How can we streamline this work?  I’ve always liked the Typed DataSet model because it did not require an Object->Relational mapping.  It allows you to model the relational model in memory, but see the relationship as a heirarchy if needed.

I am still not convinced of the simplistic DataSet view I hear from Steve Lasker.  I suspect it will take a few weeks for me to really come to a convincing conclusion so what this space for my processing of where I think data access should be in the Whidbey space.