Tech Off Thread

14 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Is there any down side to strongly typed datasets?

Back to Forum: Tech Off
  • User profile image
    Lee_Dale

    Im implementing a system where ive gone down the strongly typed dataset route.  Now apart from the overhead of having to create a strongly typed dataset everytime i need one, is there any others draw backs i havnt thought about?

    Also what's the quickest way to turn my datasets into strongly typed ones, bearing in mind i don't want to use wizards, everything is written from scratch (apart from the actual dataset classes which get created with the XSD command line).

  • User profile image
    W3bbo

    I'd just say performance, in all of my DALs I do an immediate manual conversion from DataSet/DataTable to a class that inherits CollectionBase. I understand this is the fastest way.

    Of course, strongly-typed datasets make CollectionBase dervivatives somewhat obsolete. I guess it depends on your project's circumstances.

    But I'm not really a fan of VS's generated XSDs, so there is a slight bias there Wink

  • User profile image
    Tensor

    There are a number of disadvantages. Perf for one. Another is that if you put any code in your strongly typed dataset, and then add columns and have to rebuild your datasets, kiss goodbye to your code...

    benefits? Well its the wat that MS seems to do all there examples.

    Just please dont tell me you are sending them down web services.

  • User profile image
    Tensor

    W3bbo wrote:
    I'd just say performance, in all of my DALs I do an immediate manual conversion from DataSet/DataTable to a class that inherits CollectionBase. I understand this is the fastest way.


    If all you are doing is dumpind data in to a collection, then a much faster way is to use datareaders. They are read only/forward only and are designed for exactly what you are doing. IIRC Datasets are populated by a datareader in the first place - by using datasets to populate your object graph all you are doing is addign another lot of looping.

    On the other hand if you are trying to populate a complex heirarchy of objects in one go, it can be simpler & quicker to code using datasets/datatables. It comes down to the balance of whats quickest to code versus performance. Sometimes pure perf is not the answer.

    W3bbo wrote:

    Of course, strongly-typed datasets make CollectionBase dervivatives somewhat obsolete.


    I would say thats not true. The problems are still there - if you want to do somthing crazy like encapsulate business logic in the correct place then datasets are really really not the right way to go. As I said in the first post, the moment you want to add columns to your tables or queries is the moment the probles start with datasets.

  • User profile image
    Lee_Dale

    Tensor wrote:

    There are a number of disadvantages. Perf for one. Another is that if you put any code in your strongly typed dataset, and then add columns and have to rebuild your datasets, kiss goodbye to your code...

    benefits? Well its the wat that MS seems to do all there examples.

    Just please dont tell me you are sending them down web services.



    No code will be going within the dataset class just the XSD generated code.

    Also its not being used within a web service just a local network.

    Taken what Microsoft recommend out of the equation is it better to just use the old style of ADO coding then?

    At the moment the only benefit i can see is intellisense and catching errors at compile time ?

    Which for isn't really necesary for a production system

  • User profile image
    Lee_Dale

    Also 1 more thing,

    i did contemplate encapsulating my data access within a CollectionBase derived class, could this class then be used in the same way as a dataset for binding?

    Is there any benefits to using a CollectionBase class?

  • User profile image
    Tensor

    You can bind to collections just as you can to datasts - but its not as simple as just inheriting collectionbase.

    You would probably have to make your own base collection calss which inherits from collectionbase and then implements IBindingListView. Once you have that done once though, you are set.

    Basicly, youcan get all the goodies you get with datasets, but with objects, but its none trivial to get started. Do it right though and you only have to do it once.

    If you are using .net 2.0 you might want to look at BindingList(of T).

    As a final recomendation, check out this book:
    VB version.
    C# version.

    Not all the answers to everything, but some damn good answers to some hard questions.

  • User profile image
    Lee_Dale

    Cool might invest in that book actually cheers for that

    Might just stick with Datasets for this project as i know i can do all i want with them without much messing around. 

    Might not bother with strongly typed datasets though

    cheers for your help

  • User profile image
    mabster

    Strongly-typed DataSets have two advantages over regular DataSets:

    1. When referencing a column (using, say, myDataSet.Customers.CustName) they use the integer index of the column, rather than the string index (ie Customers["CustName"]), so they're faster

    2. The partial-class implementation means that you can make changes/additions to myDataSet.cs without losing them when you regenerate the DataSet (despite what a previous poster has said).

    #2 is especially useful for adding your own code to a strongly-typed DataSet. For example, I've done wacky things like adding methods to the strongly-typed DataRow classes, so I can do this:

        CustomersRow cust = ...; // find customer
        // create a new OrdersRow with CustNumber
        // automatically populated
        OrdersRow ord = cust.NewOrder(); 

    It gives DataSet programming an object-oriented slant, making for more readable code IMHO.

  • User profile image
    ScanIAm

    Tensor wrote:

    There are a number of disadvantages. Perf for one. Another is that if you put any code in your strongly typed dataset, and then add columns and have to rebuild your datasets, kiss goodbye to your code...



    You could get around this problem by inheriting from the typed dataset object instead of modifying it directly.  I'd suspect that's the better way to do it anyway.

  • User profile image
    W3bbo

    Tensor wrote:
    If all you are doing is dumpind data in to a collection, then a much faster way is to use datareaders. They are read only/forward only and are designed for exactly what you are doing. IIRC Datasets are populated by a datareader in the first place - by using datasets to populate your object graph all you are doing is addign another lot of looping.

    On the other hand if you are trying to populate a complex heirarchy of objects in one go, it can be simpler & quicker to code using datasets/datatables. It comes down to the balance of whats quickest to code versus performance. Sometimes pure perf is not the answer.


    Now you tell me Tongue Out

    I'm not really a fan of IDataReader though, it only accepts Column Indicies as the column selection indexer, this is a real pain for me because I change my sprocs often and the only reliable way to get the right column is using the ColumnName string table.

    ...unless I'm doing something wrong?

  • User profile image
    Sven Groot

    You could use the Item property (which will always return the result in its native type, so it's a little less convenient than the Get* methods).

    Alternatively, use GetOrdinal to get the column index based on the name, then pass that to the Get* methods.

    EDIT: Both Item and GetOrdinal are members of IDataRecord, not of IDataReader, but I don't know any readers that don't implement IDataRecord (in fact, in .Net 2.0 all the provided readers derive from the abstract DbDataReader which implements both IDataReader and IDataRecord).

  • User profile image
    Tensor

    W3bbo wrote:
    Tensor wrote: If all you are doing is dumpind data in to a collection, then a much faster way is to use datareaders. They are read only/forward only and are designed for exactly what you are doing. IIRC Datasets are populated by a datareader in the first place - by using datasets to populate your object graph all you are doing is addign another lot of looping.

    On the other hand if you are trying to populate a complex heirarchy of objects in one go, it can be simpler & quicker to code using datasets/datatables. It comes down to the balance of whats quickest to code versus performance. Sometimes pure perf is not the answer.


    Now you tell me Tongue Out



    You never asked Smiley Plus most people have this irrational attachment to datasets I have never quite understood and have stopped bothering to question.

    W3bbo wrote:

    I'm not really a fan of IDataReader though, it only accepts Column Indicies as the column selection indexer, this is a real pain for me because I change my sprocs often and the only reliable way to get the right column is using the ColumnName string table.

    ...unless I'm doing something wrong?


    You are doing somthing wrong. As Sven said, you can use getordinal with a column name, and then getstring (or whatever) with that ordinal.

    A good solution is to subclass your datareader and then extend it. Have somthing like:

    public class ExtendedDatareader
       Implements IDataReader

    #region " Class Declarations "

       private _reader as IDataReader

    #end region

    #region " Constructor "

       public sub new(byval reader as IDataReader)
          _reader = reader
       end sub

    #end region

    #region " IDataReader "

       public function GetInt32(byval i as Integer) as integer implements IDataReader.GetInt32
          return _reader.getint32(i)
    end function

         public function GetInt32(byval name as string) as integer
             dim index as integer = _reader.GetOrdinal(name)
             return me.GetInt32(index)
        end function

    ' the rest of IDatReader in a similar pattern, plus the other bits which should pretty much just pass the call through to _reader.

    #end region
    End class

    Then - whenever you get back an IDataReader, just do


       dim dr as extendeddatareader

       dr = new extendeddatareader(functionWhichGetsMyIDataReader)


    You can continue to treat it as an IDataReader if you wish, but you also gain the extra overloads.

  • User profile image
    Tensor

    ScanIAm wrote:
    Tensor wrote:

    There are a number of disadvantages. Perf for one. Another is that if you put any code in your strongly typed dataset, and then add columns and have to rebuild your datasets, kiss goodbye to your code...



    You could get around this problem by inheriting from the typed dataset object instead of modifying it directly.  I'd suspect that's the better way to do it anyway.



    You would think. Try it.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.