Aren't Typed Datasets XSD really Contracts?
Roy found the xsd tool recently and got the typed datasets to scale. I still don't like them.
What is really the difference in beeing dependant on the xsd schema than a dll reference? If you do the Service Oriented approach on this problem you'll come down to what Clemens and Steve predicates these days: it's all about contracts.
The xsd schema for the typed datasets is basically just a .net platform specific contract for one given message type between the Data service layer on top of the database and the service that requests this data. Doesn't it feel a bit like WSDL? You get some xml schema type thing, use a .net framework tool and generate a class. It's the same thing.
This leads down to the question causing the most confusion in my world these days;
What place does object orientation have in a Service Oriented, message-driven, distributed architecture?
Objects can by definition not pass far connections. Messages can. So if you are building applications for a distributed environment, the OO stays in one location. Then messages are sent between these systems. This applies even to the data layer, although in a lesser degree.
In this case, if the datalayer is so tightly bound to the service that you don't need a message contract, but can use a TDS, I can't really see why this application couldn't have used regular business entities in a shared assembly.