strongly typed ADO.NET datasets

DJFuji

Diamond Member
Oct 18, 1999
3,643
1
76
For those that know ado.net/asp.net architecture well, i'd like to get your opinions on strongly typed datasets. I posted at asp.net but didnt receive any response.

I've always used a 3-tiered architecture with untyped datasets for my enterprise applications with a presentation, business, and data access layer talking to SQL. But recently i read an article that said strongly typed datasets are vastly superior in terms of speed and development type because they enable the use of intellisense in ado.net.

I actually went ahead and tried it and found that a) yes development time WAS faster because a ton of code is autogenerated for you that youd normally have to write yourself, but b) that strongly typed datasets seem to "couple" the layers in an n-tier structure too much. Instead of having independent tiers that are modular, you have too much codependence on each other.

One example is how you get a dataset to bind to a datagrid in the presentation layer. You have to call the business layer which calls the data layer which talks to the database to return a dataset through the layers again. That's how i used to do it. But because strongly typed datasets are STRONGLY typed, you now have to pass through the layers an object instantiated from an inherited dataset CLASS. This means that the class has to either exist in some centralized module apart from the other layers, or that each layer has to reference the data layer in order to create a local object of type "strong dataset".

How are other developers doign this? By creating a "StrongTypeDataSet" tier that only holds the dataset classes? Or by making the presentation layer directly reference the data layer?
 

UCJefe

Senior member
Jan 27, 2000
302
0
0
I am a huge fan of strongyl typed data sets and the productivity gains you get in development. The performance hit you take is minimal in my limited testing. The strongly-typed vs untyped argument though is fairly religious and you will have zealots on both sides of the fence.

My DataSet's normally live in a web service which contains most of the business logic and data tier. This has the nice side effect of when you reference the web service in yur client app, all of the code for those strongly typed datasets is brought down in the generated Reference.cs class. If you ever change the strongly typed data sets on the server, all you need to do is refresh your web reference and you have all that new code. In this case, it's kinda like having a little local copy of your data layer (at least the classes anyway) available to any other layer (presentation, etc).

In your case, you have a few options. You could always just deal with untyped DataSets in your presentation layer. Your business layer would actually be handing back a typed DS, but your presentation layer doesn't have to know that. Of course you lose all the benefits of having typed objects in the first place, but if you're not touching the datasets other than to bind, this may not be an issue.

Otherwise, you need to have those classes around somewhere. If you don't want to bring in your whole data layer, your best bet might be to (like you said), create a separate assembly/namespace (not sure how you are paritioning things) where you have all your datasets which can then be referenced from anywhere that needs those classes. As long as your presentation layer just uses the data and doesn't try to read it out fo your DB or make fancy business decisions in your Click handlers you'll be ok.

It's good to see that you're actually thinking about this and not just throwing everything into MainForm.cs like I've seen so many times before. :)
 

DJFuji

Diamond Member
Oct 18, 1999
3,643
1
76
I'm kind of glad there wasn't this magic secret that I was missing with regard to strongly typed or untyped datasets. I've never used web services but the prospect of having ANY MS engine autogenerate code for me makes me nervous (have you ever tried to drag and drop elements in frontpage?)

On the other hand, though, the code generated by using design time elements and strongly typed datasets does look fairly clean. It's not as streamlined as i would write myself, but it's likely less buggy because there's less human error to worry about. I do like the intellisense with ado.net though.

You mentioend that i could have the presentation layer deal with untyped datasets and have the biz layer hand back typed ds. Won't there be some sort of type mismatch here? I've tried instantiating an untyped dataset and setting it equal to a biz class method that returns a typed ds. ASP.NET threw a type error, as i expected. Even though the typed datasets are inherited from the untyped ones, i couldnt get them to "auto-cast", if you will. This might be a good solution for me since i mostly use the datasets to bind in the presentation layer. I try to keep all other logic in the biz.

I'm also considering making another tier called 'datasets' that contains the typed dataset classes and just having that be available to all the other layers like you said. That might be a viable solution. The only thing the presentation layer would need it for is to instantiate typed datasets to be filled by data coming from the biz layer.

The biggest concern I have is that everything seems so 'clunky' compared to hand coding a data layer and doing everything at runtime. I followed the 15seconds.com tutorial on creating strongly typed datasets through 'datahandler' components where you drag and drop a conenction and sqldataadapter onto the "page" and then right click the sqlda and click 'generate dataset' so that it creates an xsd file. It works fine but I dont like the fact that if i need to do more than one select, insert, update, or delete query, i have to create ANOTHER SqlDA on the page to run different sprocs. I suppose i could do that at runtime like i usually do, but doesnt that negate the whole purpose of design time setup of these objects?
 

KB

Diamond Member
Nov 8, 1999
5,406
389
126
I have never used strongly types datasets and after reading about it (maybe I misunderstand it) I don't think I will. Intellisense is great, but I love having direct access to the dataset and its tables. In addition my datasets are frequently changing as the client wants some fields removed and others added.

In my case the presentation layer doesn't need to know about the concept of a dataset, with the exception of a datagrid. It just calls the update or insert method of a business component (that stores the bound dataset) and it handles the data layer communication.
 

DJFuji

Diamond Member
Oct 18, 1999
3,643
1
76
Well the presentation layer must still instantiate a dataset in order to have some local object to bind the dg to. In the case of strongly typed datasets, that dataset must be an instance of a strong typed ds class, meaning you have to directly reference the data tier. But the supposed 200% performance increase and faster RAD with strongly typed DS have me curious.
 

WannaFly

Platinum Member
Jan 14, 2003
2,811
1
0
I really wish i knew more about this subject to contribute. Ive used Strongly typed DS's a couple times.
 

UCJefe

Senior member
Jan 27, 2000
302
0
0
Originally posted by: KB
I have never used strongly types datasets and after reading about it (maybe I misunderstand it) I don't think I will. Intellisense is great, but I love having direct access to the dataset and its tables.

What do you mean? You can. ds.SomeTable vs ds.Tables["SomeTable"]

In addition my datasets are frequently changing as the client wants some fields removed and others added.

This is true and is a bit of a pain with strongly typed data sets. If your schema changes, you need to change your SQL, your DS and any code that references the fields you change. In the untyped case, you won't need to change the DS. On the flip side, any errors that result from your schema change are run-time errors whereas in the strongly typed case, they will be compile-time. But the fact remains that yes, with a strongly typed DS, if you have frequent schema changes it may become a pain. Why you are changing your schema frequently is your business. :)

In my case the presentation layer doesn't need to know about the concept of a dataset, with the exception of a datagrid. It just calls the update or insert method of a business component (that stores the bound dataset) and it handles the data layer communication.