none
DataSets: To Type or Not to Type...? RRS feed

  • General discussion

  • -EDIT By rkimble-

    This thread became a sub-discussion from the thread http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1754690&SiteID=1 and was split out and moved here to encourage additional responses and to return the other thread to topic.

    -End EDIT-


     

    I don't have any advice regarding your problem specifically, but I do have advice for a *different* solution to your original problem.

     

    We (my company) don't use typed datasets at all. This SIGNIFICANTLY reduces the amount of code we have to maintain. (As you know - code that is generated still has to be maintained. So for me - generating literally thousands of lines of extra code to use typed datasets it not exceptable.)

     

    To see a very simplistic example of NOT using typed datasets, check this out:

     

    http://www.insteptech.com//Downloads/PurchaseTracker.zip

     

    Hope this helps!

     

    Monday, June 25, 2007 7:51 PM

All replies

  •  DeborahK wrote:

    ... 

    We (my company) don't use typed datasets at all. This SIGNIFICANTLY reduces the amount of code we have to maintain. (As you know - code that is generated still has to be maintained. So for me - generating literally thousands of lines of extra code to use typed datasets it not exceptable.)

    ...

     

     

    To both Ben and Deborah,

     

    I have to argue the logic of creating your own datasets when they only reproduce existing functionality of designer genereated datasets; the same goes for not using strongly typed datasets at all...  it's just not logical... 

     

    First of all, you haven't cut the code down by much.  Ben, your example requires maintaining a lot of custom code without the ease of telling the dataset designer to regenerate the dataset.  And on that note, Deborah, what is there to maintain with designer generated code?  The designer code only needs to be changed if the database schema changes or if you need to modify your data objects - and this can be done with a couple clicks in the designer - much faster than editing handwritten code.  There's also little need to worry about the number of lines of design time code anyway - it all gets translated into MSIL during compile so the amount of code during development doesn't necessarily reflect the final code in the assembly.  And, as stated, you are "maintaining" that code through the designer with simple mouse clicks in a GUI.

     

    There's also the fact that using generic DataSet and DataTable objects has robbed you of so much power...  If you don't have inherited data classes you can't take advantage of the partial classes and data layer logic.  The ability to put custom code direclty into the data objects is wonderful.

     

    And then there are the potential developer mistakes of mistyped column names, invalid indexes, and other typos that are all avoided by using the stronly typed datasets.  Think of the schema documentation required when you don't use strongly typed datasets...  In a development team, only one developer needs intimate knowledge of the database schema to create an assembly containing the strongly typed DAL.  Then the rest of the team can just work with the DAL assembly and not worry about actual database schema - that's all been wrapped up in the dataset.  Another scenario is a web service.  IF the service returns a generic datatable then consumers need schema information in order to code against the web method; with strongly typed datasets the schema is self apparent.

     

    Finally, it seems unlikely that an individual would be able to recreate ADO.Net in a way that significantly outdoes what the .Net team created.  A lot of thought and a lot of research went into the development of the dataset designer.  And if the current community is any indication, it seems like they did a heck of a job.

     

    I guess the moral of the story is that you can't reinvent the wheel - you can only create another kind (think Tweel).

    Tuesday, June 26, 2007 3:22 PM
  • Yes, one of these days I need to take the time to develop an application both with and without typed datasets to show how much code you actually do save NOT generating typed datasets.

     

    Until that point, I don't have much to suggest other than to look at my code, which is posted here:

     

    http://www.insteptech.com//Downloads/PurchaseTracker.zip

    Wednesday, June 27, 2007 8:15 PM
  • Again, number of lines of design time code does not directly translate into number of lines of compiled code - so I'm not sure what you're saving...

     

    And in the end, even if you do eliminiate, say 1000 or so lines of designer generated code, you've given up a lot of very useful, very powerful functionality with the only "potential" benefit being a smaller assembly size.  But if we're talking about a few kilobytes difference in compiled assembly size (even a meg - which would represent an enormous amount of code), I can't see a reason to avoid the typed dataset.  On the Compact Framework you might think about it if the app is going to be quite large, but on the desktop I don't see any benefit - only a lot of drawbacks.

     

    I'm curious to hear other opinions on the subject - or solid logical reasons not to use typed datasets.

    Wednesday, June 27, 2007 9:52 PM