in Search

Do you Twitter? Follow us @CodeBetter

Brendan Tompkins [MVP]

Blog First. Ask Questions Later.

The Problem with Typed DataSets?

OBSOLETE CONTENT
The author of this post has determined that this content is obsolete. Use at your own risk! Blog posts are a point-in-time snapshot of the blogger's thinking and should not be assumed to represent this blogger's current opinions. This post was left up for historical purposes.

Yesterday afternoon, I listened to the latest version of DNR, with DonXML. Good show as usual. I especially liked hearing those South Jersey accents. I have family there and I think the way they talk is cool. I've been saying “youse guys” all day. Rory, I hope you feel better.

Something that they discussed in the show has been bugging me, because it's a topic that hits me close to home. DonXML was asked, “What's the problem with Typed DataSets?” His answer was, generally, that there's no good way to add Business Rules to typed DataSets. See his post here for his full justification. One of the things I totally agree with is that the XSD to Typed DataSet class mechanism in .NET could be more open. I mean, somewhere in there, there's got to be an XSLT transformation involved, right? Why isn't this transformation file open for extensibility? Now, I can guess that it's just not that simple, and the developers choose to instead opt for the extensibility by sub classing a Typed DataSet model instead. But then my question becomes, if you want to extend the DataSet, why not subclass it? Isn't this a good way to add Business Rules if you needed to?

But an even bigger question to me is, why would anyone want to add business rules to a common tier component like a DataSet? I mean, isn't this what the business tier is for anyhow? I'm wondering if I've fundamentally misunderstood something.

I bring this all up because I LOVE using Typed DataSets. Especially the DataAdapter. Without the DataAdapter, I just don't know what I'd do. Without Typed DataSets, the DataAdapter isn't of much use to me. Can someone help me understand this argument?

-B

Published May 04 2004, 08:31 AM by Brendan Tompkins

Filed under: .NET General

Comments

Frans Bouma said:

What you'd like to add are 2 things:
1) per field validators, such as 'Total >= 0'
2) per row validators, such that you can trigger 'ShippingDate >= OrderDate'.

These validators have to be triggered on different times. The field validators when you set a value, the row validators when you call for example "Validate" or when you're trying to save a row to the database.

When you can plug in these kind of validators, you can simply 'set and forget': create the typed dataset instance, load it with the data required, add the 2 validator objects, pass it on to another tier.

# May 4, 2004 5:34 AM

Brendan Tompkins said:

Frans, thanks for the clarification. That helps. Can't you sub-class a typed dataset if you need this? I'll admit this is tedious.

# May 4, 2004 6:13 AM

DonXML Demsak said:

Typed Datasets are really just to make a dataset strongly typed, not used as a business tier, but I find way too many developers misusing typed datasets for just that purpose, as business entities. That is my problem with them, the over use of them. It is that whole domain versus table model agruement. Microsoft pushes the table model of development with VS.Net since the majority of applications developed with VS6 were for small applications (aka applications with very little in the way of business logic). As an enterprise developer, this is not the norm for me, and since VS.Net has grown into more of an enterprise application IDE, I think it has outgrown forcing the table model on the developer. But that is just my opinion, your milage may vary.

# May 4, 2004 6:49 AM

Brendan Tompkins said:

Thanks Don! My experience is in using DataSets for Common tier stuff. I'll need to school up on the table vs domain argument. By the way, do you know anything about the guts of the XSD tool? Do you know if it uses XSLT? If so, are there any plans to open up the transformation to developers?

# May 4, 2004 7:01 AM

DonXML Demsak said:

Yes, you can enhance the XSD tool using your own namespace within the XML Schema and extending XSD.exe, but I haven't done it myself but Scott Hansleman has done it. I'll see if I can dig that stuff up.

# May 4, 2004 7:26 AM

JosephCooney said:

Typed dataset generation is extensible via CodeDom manipulation. xsd.exe uses a class in the framework called TypedDataSetGenerator that lives in the System.Data namespace. It has a Generate method that takes a dataset, a codenamespace and an ICodeGenerator (think VB.NET, C#). After Generate has been called you can manipulate the CodeDom items in the namespace you passed it to your heart's content. Daniel Cazzulino has some more info here (altho I think his code had some issues with nested types, can't recall exactly): http://weblogs.asp.net/cazzu/archive/2003/10/24/33302.aspx

# May 4, 2004 3:22 PM

Brendan Tompkins said:

This is cool stuff. Thanks Joseph!

# May 5, 2004 1:49 AM

JosephCooney said:

Typed Dataset Generator

# May 18, 2004 10:57 AM

Kevin Cunningham said:

I have always been a big Domain Model fan when it comes to building solutions. I am trying to expand and get a little familiar with a typed data set solution since I have been told it can be easier and have a faster time to marker. I have seen *sample* apps built using the Table Module design pattern. Which is pretty slick for the 1:1 relationships, but NONE of the sample apps reference relationships or object hierarcy. The sample ususally have a linear model with a web page updating a order but not and order and order detail.

The typed dataset approach seems to me very restricting. The fact that I am giving up things like inheritance and direct object relationships seems "unnatural". The only gain I am seeing seems to be in intial dev but the cost is high.

For example, you have a customer detail typed dataset, customerData.xsd. That customer has orders. Orders are all around the system so you create CustomerData.xsd. Now one service interface is GetCustomerDetail, returning the simple CustomerData dataset here is easy. Then there is a GetCustomerOrders. The data return needs to be both customer info and order info ... how do you do that when you have 2 *dataset* defined? It seems that the fact that they are both defined as datasets is an issue. Of course I could go define a new dataset than has both but where's the benefit there. Then I just end up with a gazillion data tables and am in the business of maintaining duplicate representations of entities ... or is
that the idea??

# August 20, 2004 5:41 AM

Name (required)

Your URL (optional)

Comments (required)

Remember Me?

Enter the numbers above:

Add

About Brendan Tompkins

Brendan has been programming with .NET since the first public beta and is owner and operator of Port Technology Services, a consultancy company providing .NET application development services to the Maritime industry. In July, 2007, he was awarded the Microsoft MVP award for ASP.NET. He's also a proud co-founder of failed .COM startup Intrinsigo, and has had a hand in the failure of numerous other businesses. He currently runs CodeBetter.Com and Devlicio.us, and lives in Norfolk, Virgina with his wife Tiara and son Ian.

This Blog

Home
Contact

Syndication

News

This work is licensed under a Creative Commons Attribution 3.0 License.

Brendan Tompkins [MVP]

The Problem with Typed DataSets?

Comments

Frans Bouma said:

Brendan Tompkins said:

DonXML Demsak said:

Brendan Tompkins said:

DonXML Demsak said:

JosephCooney said:

Brendan Tompkins said:

JosephCooney said:

Kevin Cunningham said:

Leave a Comment

About Brendan Tompkins

This Blog

Syndication

Recent Posts

Tags

News

Archives