Typed Dataset or Custom Classes

Typed Dataset or Custom Classes

• CraigInCalifornia

  Hi Leo
  
  I would say that you want typded datasets when you want to use datasets in your architecture.
  
  A coupe of the benefits of typed dataset over a bog standard dataset are:
  
  Strong typing - The return value of .Item in a standard dataset is Object, when your dealing with value types such as Int32 et al, your going to get a lot of boxing operations which will hurt performance.
  
  Cleaner code - customer.Name is a lot easier to read than customers.Tables("Customer").Rows(0).Item("Name").ToString. Throw all that into a complex conditional statement and your lines will get pretty long.
  
  Compile time error checking - you don't want to find out at runtime you've miss-spelt something, especially if it's in a large solution with many many projects, it can be 10+ minutes before you get the nasty object not set error that tells you you typo'd. Worse is if it's in a branch of the code that isn't covered by unit tests (if you have any) and surfaces after a release much to everyones annoyance.
  
  Intellisense - nothing needs saying here
  
  I've found that dataset usage encourages developers to use a procedural style programming approach to code rather than using a full OO domain model unfortunately. This is still possible when your custom classes focus on holding data as well instead of encapsulating behaviour as well as data. Martin Fowler calls this anti-pattern an anaemic domain model.
  
  It often boils down to the skill set of the development teams that will be coding to your architecture, if they don't have strong OO experience then asking then to code to a domain model rather than the quazzy procedural style used with datasets can sometimes cause more problems than it's worth.
  
  Note that all of the benefits i listed for typed datasets over untyped still apply to custom classes and often the investment in a good domain model pays dividends later
  
  An ounce of prevention is worth a pound of cure after all, I forget where this quote came from
  
  Hope that helps
  
  Regards
  
  Ed
  
  
  
  

• nicolajbor

  James Kovacs wrote:

  RE: Doing both If you mean customize the generated code, I would strongly recommend against it. Modifying generated code is dangerous because you've got no way to regenerate it. You can also run into problems if your tool (such as VS) decides to regenerate it for you. If you mean wrap your own custom code around a typed dataset, that is possible and I've seen it done. You basically use the typed dataset as a dumb data holder. It can get complicated when you have references between objects, especially when the objects do not fit nicely into a strictly relational model. So wrapping typed datasets is not my first choice, but it is possible and preferable to modifying generated code.

  Wrapping the custom code around the dumb data holders works well for me. Things can be simplified by using multiple table/dataset adapters in the some component to handle the various parameterized queries.

  
  
  

• paso

  I haven't seen grave performance problems with typed datasets. There is no magic in typed datasets. They simply wrap an untyped dataset and perform casts for you. So that is where the perf hit probably comes from - the hidden casts whenever you get data out of a typed dataset. If you're using untyped datasets, you will have to explicitly do the casts yourself. When dealing with custom classes, you have more control over your parsing/casting, which is the route that I prefer. Like anything in performance, your mileage may vary and you should try things out in a minimal implementation of your target architecture.
  
  
  

• lokeshbohra

  I fully agree with Ed on the usage of dataset usage while doing concurrency checks like acceptchanges etc.

  But the query raised by Ayhan is similiar to what i have.

  As per my understanding,typed datasets are used:-

  1)Depicting a table as an xsd at the aplication time so that schema checking can be done at the compile time

  2)when we want a customised dataset which will gets its values from different columns of different tables.

  3)Typed datasets do degrade the performance of a application by an significant amount

  Also custom classes which Ayhan is talking about are active record(entity) representation of tables at the application(DAL end).Am i correct

  Please throw light on when should we typed datsets and what are their merits and demerits.

  regards

  
  

• K.V.Bharath

  I still have one query of this.

  On many fronts, i have been told that typed datasets poses a grave performance problem comapred to using a simple untyped dataset

  or custom classes.

  Is that true.If yes then please let me know as to how to judge when to use typed dataset and when not.

  One more thing, if a tool is generating DAL automatically,is ther some way that we can geenrate typed dataset out of that

  Regards

  
  

• Alexei_shk

  Do both --

  Create the typed dataset in a data access component and expose/customize the methods however you see fit. If you break one of your custom methods exposed in the component, you'll find out about it at compile time.

  public personList GetMiddileIntialList( char MI) { ... }

  you can put all manner of dataviews and the like in the component and build domain specific queries... Intellisense will make them extremely reusable --

  
  
  

• kp6452

  So..

  Thanks you all... But please forgive my poor english. I still didn't get which one is better :)

  What are the down sides and positive sides of custom classes and.

  And finally what is the down and positive side of the Typd datasets

  I apologize if I'm being pain in the neck :)

   

   

  
  
  

• tackett

  I had to make this decision recently and I chose to use custom classes and strongly-typed collections instead of datasets. Here is my reasoning:
  
  1) The system that I'm developing rarely has to do any bulk operations. It's mainly just individual CRUD operations with lots of queries in between. My understanding is that the primary advantage of the dataset is in it's ability to essentially disconnect from the DB and allow you to do work without tying up a connection. This is not an issue for me.
  
  2) Datasets are notoriously slow when compared to datareaders. Since most of my CRUD operations are done using Stored Procedures via the Enterprise Library Data Access Application Block (DAAB), my only real concern is how fast I can read the results of queries.
  
  The speed of DataSets vs. DataReaders is outlined here:
  
  http://www.devx.com/vb2themax/Article/19887/1954 pf=true
  
  Of course the issue with DataReaders is that you have to manage DB connections, but the DAAB does a good job of mitigating that concern. and if you're writing DB code you should learn able to do this effectively anyway.
  
  3) I wanted to create a application that was maintainable outside of Visual Studio The whole typed dataset thing appears to be tethered to VS as it is VS that launches the wizards and generates the code and whatnot. My application is sufficiently complex and sensitive as to where I really need to be directly responsible for the design and implementation of every line possible. Auto-generate always sends a chill down my spine unless I am building the templates.
  
  As it turned out, I came up with a solution that appears to be much more efficient than Typed Datasets. Custom objects and strongly-typed collections populated with these objects just feel much more natural and are immensely flexible. Your Mileage May Vary though.
  
  

• Breckish

  Which one is better depends a lot on what you plan to use your typed datasets or custom classes for. Either can be used as a dumb data-holder for transporting values from the database to the UI. The advantage of custom classes is that you have somewhere to put domain (aka business) logic. Let's say you have a Customer object with FirstName, MiddleName, LastName, Salutation, etc.. You need to return the FullName of the Customer, which involves examining which name fields are not empty and joining together the information. With a typed dataset, you will have this logic in a helper object to encapsulate it. (Hopefully you don't scatter the logic throughout the code.) You hope that future developers find the helper object and use it rather than reimplementing the FullName logic. With a custom class, you can create a FullName property that encapsultes the logic. It's easy for future programmers to find because they'll be looking at this object anyways.
  
  Personally I prefer rich objects with behaviour over typed datasets as they give me somewhere to organize all the complexities of the business logic.
  
  
  

• Lakshmi N

  RE: Doing both
  If you mean customize the generated code, I would strongly recommend against it. Modifying generated code is dangerous because you've got no way to regenerate it. You can also run into problems if your tool (such as VS) decides to regenerate it for you.
  
  If you mean wrap your own custom code around a typed dataset, that is possible and I've seen it done. You basically use the typed dataset as a dumb data holder. It can get complicated when you have references between objects, especially when the objects do not fit nicely into a strictly relational model. So wrapping typed datasets is not my first choice, but it is possible and preferable to modifying generated code.
  
  
  

• Redburga

  Hi Ayhan
  
  I've found that over time the auto generate savings of typed datasets save you time when what your doing won't actualy take that long in the first place.
  
  For example, adding a column, it takes no time at all to add a vaiable and property to a custom class. It quicker with a types dataset but your not saving much time.
  
  The time savings that come from custom classes is in the long (usually very long) maintenance phase of the project. Custom classes allow you to compse them as you see fit, a typed dataset is inheriting from dataset already which limits how you can structure your classes slightly. Structuring things with relationships is cumbersome.
  
  It's usually comes down to the size of the system your writing and what features you need your sutom classes to exihibit. Smaller applications, use a dataset. For larger applications you going to run into issues that make using the datasets in built features less desirable anyway, different types of locking in the DB, performance requirements, larger number of developers thus increasing the need for maintainable code.
  
  Binding isn't an issue so in short if your code is giong to be full of .ModifiedOriginal, .ModifiedCurrent, .AcceptChanges etc then go with the dataset.
  
  If your using custom classes now your not doing any of that any way.
  
  Regards
  
  Ed
  
  
• Typed Dataset or Custom Classes