Naked objects or datasets? This is the kind of sexy argument that we have in the .NET development world. I bet you’re getting hot just thinking about naked objects aren’t you?
The crux of the issue is that naked objects, or perhaps data transfer objects (DTOs) are self-defining, and can be easily serialized to an XML file that any client system should be able to read and then reconstruct the object from the data within the XML file. Datasets on the other hand are best defined as ‘containers’ of data that roughly represent the data structure of the source data (e.g. database tables). They can also be serialized, but argument goes that you have to inspect the dataset to determine what data is inside it, before acting on that data.
Microsoft have a halfway-house in .NET, which they call ‘typed datasets’. They behave like datasets, but also contain type information so you know, for example, that if you have a
Customer table in your dataset, you can call
Customer.Name to get the value in the
Name column. One of the arguments against typed datasets is that all the code to manage the behaviour of the dataset is unnecessary overhead, when all that you are passing around is the values of the data.
Unboxedsolutions.com has an interesting discussion on the DTO vs Dataset argument, with reference to Martin Fowler’s Patterns of Enterprise Application Architecture (Fowler is a development guru with some interesting articles on application development in general). Basically the argument is that if you are in control of both ends of the data ‘conversation’, and you are using .NET as your platform of choice, then typed datasets offer benefits in terms of visual tools and time-saving features that elevate them to the preferred choice over DTOs in that particular environment.
To expand on the argument, I imagine that some would say “but what if the application changes in the future to include heterogenous client systems?” This raises another of my pet peeves: don’t be afraid of refactoring! I have lost count of the times that I (and others) have turned a string of ‘but what if…?’ statements into a hugely versatile system that never gets used. What is the point of developing a fantastic loosely-coupled, fine-grained, n-tier system if the client has asked for only a WinForms front-end? Sure, the requirements may later change to deliver some functionality via web pages or web services or something, but you can build those requirements in at a later date.
In the DTO vs datasets example, we can build a .NET system using typed datasets in a very rapid manner because of all the wonderful Visual Studio tools. If we then have a requirement change that requires us to service Java clients via web services, we can at that point decide to either tranlate our datasets at the service layer, or refactor the system to use DTOs throughout.