What are the disadvantages of Typed DataSets
I come from a world that favors building your own rather than rely on libraries and frameworks built by others. After escaping this world I have found the joy, and ease, of using such tools as Typed DataSets within Visual Studio. So besides the loss of flexibility what else do you lose? Are there performance factors (disregarding the procs vs dynamic sql debate)? Limitations?
Answer
Typed datasets are by far an upgrade from the world of classic ADO disconnected recordsets. I have found that they are still nice to use in simple situations where you need to perform some sort task that's row oriented -- i.e. you still want to work in the context of a database paradigm of rows, columns, constraints and the like. If used wisely in that context, then you're OK.
There are a few areas where their benefits diminish:
- I think the synchronization issues brought up here already are definitely a problem, especially if you've gone and customized them or used them as a base class.
- Depending on the number of data tables in the dataset, they can become quite fat. I mean this in the sense that multi-table datasets typically present a relational view of data. What comes along with that, besides the in-memory footprint, are definition of keys and potentially other constraints. Again, if that's what you need great, but if you need to traverse data quickly, one time, then an efficient loop with a data reader might be a better candidate.
- Because of their complex definition and potential size, using them in remoting situations is ill advised as well.
- Finally, when you start realizing you need to work with your data in objects that are relevant to your problem domain, their use becomes more of a hindrance than a benefit. You constantly find yourself moving fields in and out of rows tables in the set and concerning yourself with the state of the tables and rows. You begin to realize that they made OO languages to make it easier to represent real-world problem domain objects and that working with tables, rows and columns doesn't really fit into that way of thinking.
Generally in my experience, I am finding that complex systems (e.g. many large enterprise systems) are better off moving away from the use of datasets and more towards a solid domain specific object model -- how you get your data in and out of those objects (using ORM's for example) is another topic of conversation altogether. However, in small projects where there's a form slapped in front of data that needs to basic maintenance and some other simple operations, great productivity can be acheived with the dataset paradigm -- especially when coupled with Visual Studio/.Net's powerful databinding features.