none
Typed Dataset or Custom Classes RRS feed

  • Question

  • Hey friends,

    I am a VB developer, soon I am going to start a new project. It will be a client application, I will use a SQL server database.

    I am used to use custom classes, I create my onw variables properties, events and methods.

    I am aware of the Typed Data Set and thinking about using it on my new project. The problem is that  I have never used it,  I do not know the minuses and plusses of the Typed dataset. Now, my boss and me on the desicion phase, we want to implement the most efficient and easy maintainable one. If you ask me , I'm quite happy with custom classes :))

    My opinion is that the custom class is better for performance purposses, because I  create properties and methods, only which I need. With the typed dataset there will be many property which I won't need,

    Typed Dataset has a very big plus, it creates everything automaticly,    beside that I can create my own tool to create my custom classes, DAL and stored procedures.

    Is there somebody can give me some idea on that?

    When compared the custom classes and typed dataset, which one is better and why ?

    Probably I will have to change my database during the project, maybe adding or removing fields... Therefore I also will have to change my classes, DAL and the stored procedures. It is very irretating to do such things in the midle of the project but  it is how it goes :)  Could you please consider this issue when aswering my question. Which one  is easy to maintain?

    Please give me some good reasons to keep going with custom classes ;)

    Thanks a lot...

    Regards

    Ayhan

     

          

    Friday, December 1, 2006 10:00 PM

Answers

  • 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.
    Tuesday, December 5, 2006 7:40 PM

All replies

  • 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
    Saturday, December 2, 2006 11:09 AM
  • 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

    Tuesday, December 5, 2006 10:40 AM
  • 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


    Tuesday, December 5, 2006 6:53 PM
  • 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 :)

     

     

    Tuesday, December 5, 2006 7:28 PM
  • 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.
    Tuesday, December 5, 2006 7:40 PM
  • 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

    Wednesday, December 6, 2006 12:49 PM
  • 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.
    Wednesday, December 6, 2006 9:28 PM
  • 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 --

    Monday, December 11, 2006 6:15 PM
  • 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.
    Monday, December 11, 2006 8:43 PM
  • 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.
    Tuesday, December 12, 2006 3:57 PM
  •  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.

     

    Friday, December 15, 2006 1:32 AM