What are the disadvantages of Typed DataSets

Question

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 usin

Answer 1

The main criticism I would extend is that they don't scale well -- performance suffers because of the overhead, when you get to higher number of transactions, compared to lightweight business entities or DTOs or LINQ to SQL. There's also the headache of schema changes. For an "industrial strength" architecture, they're probably not the way to go, they will cause issues in the long run.

I would still definitely use them for quick and dirty PoCs or simple utilities -- they're really convenient to work with given the tooling in Visual Studio, and get the job done.

Answer 2

I only gave Typed Datasets a very short try. I stopped when I found my code breaking about 2/3 of the way down a 1,000+ line file of generated code.

The other thing I didn't like was I thought I'd get to write code like Customer.Name, but by default I seemed to get code like CustomerDataSet.Customers[0].Name, where Customers[0] was of type CustomersRow. Still nicer to read than untyped datasets, but not really the semantics I was looking for.

Personally I headed off down the route of ActiveRecord/NHibernate, and haven't looked back since.

Answer 3

Performance is improved with typed datasets over untyped datasets (though I've never found performance issues with trivial things like that worth worrying about).

I'd say the biggest pain is just keeping them in sync with your database--I can't speak for VS 2008 but prior versions do not provide good support for this. I literally drag the procs onto the designer everytime the resultset's schema changes. Not fun.

But, you do get compile time type checking which is great and things like Customer.Name instead of Dataset.Tables(0).Rows(0)("Name").

So, if your schema is relatively static, they may be worth it, but otherwise, I wouldn't bother.

You could also look into a real ORM.

Answer 4

There is nothing wrong with typed datasets. They are not not perfect, however it's a next step toward solution of object-relational impedance mismatch problem. The only problem I faced is weak support for schema changes. Partial classes can help but not in every case.

Answer 5

I'm not a big fan of typed dataset. There is no way that I can improve the performance using typed dataset. Its purely a wrapper over the existing database objects. I cannot consider the access like employee.empName. Casting is still done in the wrapper. Another overhead is huge chunk of code. LOC is increased. So many active objects in memory. No automatic update of schema. In any way typed dataset is not useful for developers except the comfort that it gives. As a developers we don't have any right to demand for comfort :) Take the pain...take the pain out of user :)

Answer 6

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.