Why you should never use the DataSet or XMLDom

OK, so that's quite controversial. I probably shouldn't say 'never', but I think it's usually a good indication of bad application design when the DataSet or XMLDom appear as central parts of the application architecture. So why shouldn't you use them? The simple answer is there is a much better way, the 'business object model' or 'domain model'. Pretty much all the enterprise application architecture gurus now favor centering an application around a central object oriented model of the business data. The DataSet and XMLDom are both ways of holding structured data in memory and they both suffer from two huge drawbacks compared with an OO approach: 1. They are not strongly typed. You can put any kind of data in a DataSet or XMLDom, you can dynamically change the 'schema' at runtime and you no way of ensuring that the structure you are expecting is the structure that is actually there until runtime. You are throwing away your first and best line of defense, the compiler, because the compliler can know nothing about your schema. 2. They break encapsulation. In the OO world the operations on data and the data itself are tightly coupled in the same class file allowing the class to only expose a very controlled interface to the outside world. That's the essence of encapsulation. Both the DataSet and the XMLDom are amorphous blobs of data that have to be operated on by code that has no instrinsic link to that data. You have no easy way of looking at all the code that operates on the data because it's spread throughout your application and you have no way controlling the access to that data because it's interface is not controlled. So what should I be doing? Firstly you should design your application around a 'domain' or 'business object' model. I strongly recommend Eric Evan's Domain Driven Design for a powerfull discussion on why's and hows of 'Domain modeling' and Rocky Lhotka's Expert C# Business Objects for a practical guide to building business object models with C#. He even provides a complete application framework, CLSA, that you can build your applications with. The next version of Visual Studio will come with Whitehorse, a fully intergrated class documentor/generator that will make designing and building domain models a joy. Now, instead of reading your data from SQL Server or XML into a DataSet or DOM, you write code to read the data into your domain objects. Reading relational data usually means cutting your own object-relational code although there are now some open source projects, such as NHibernate, that can supply an object-relational framework off the shelf. Microsoft also announced an object relational mapping tool, Object Spaces, but I understand that it's been dropped from .net V2.0. I'm still not quite persuaded how robust, secure or scalable these are, but I'm open minded about trying them out. With XML the .net framework makes it very easy if you have control over the XML Schema and your domain model simply to use XML serialization to stream XML to objects and objects to XML.