Well, you miss some VERY interesting points here :-) Typed data does NOT mean additional fields, not by default.
But it means for example changed functionality. Take an accounting system. Account type can be a code that can determine whether a certain transaction goes through or not - all other stored data is identical. With our solution, you can create account objects and have subtypes depending on a specific value of a field. We use this in our CMS - we have around 20 different container types, NO additional fields. But we can use reflection and attributes to see what subcontainer is valid below another subcontainer. This allows me to ovverwrite functions in the business object depending on data values - as long as you dont load addiitonal data, performance losses are nonexistent. As I said - I prefer to have compiler errors instead of runtime errors :-) But your dataset work is interesting - we go in different directions, but your steps make PERFECT sense in the context of the way you are going to :-) Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -----Original Message----- From: Ben Kloosterman [mailto:[EMAIL PROTECTED]] Sent: Donnerstag, 10. Oktober 2002 13:47 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Strongly-Typed DataSets vs. Strongly-Typed Collections You dont :-) In addition Im not a big fan of typed DB data anyway. Datasets are strickly designed to work with relational databases. RelationalOO and OO DB's are not mainstream yet - they still loose out in a big way to their relational brothers. These are growing and these fit in perfectly with what your doing . Note I am not changing datasets just building a cache , a compressor , autoupdater and autoDbaccesslayer. I have worked on a few projects which used strong datatypes ( not .NET ) when a dataType was added or changes you had to change 1000's of line of code. After this I gave up strong typing for handling database data.. For those reading that doesnt mean your program should refer to everything as Object or void* its just the DB data . I have used some code in the client cache which converts an untype dataset to a typedataset , but the benefits of typing here are not worth the extra time to code and maintain in. Nevertheless I have done it soemtimes because it looks "neat". Ben -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]]On Behalf Of Thomas Tomiczek Sent: Thursday, 10 October 2002 6:10 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Strongly-Typed DataSets vs. Strongly-Typed Collections Well, just one question - how do you handly type inheritance in this dataset? I mean, a typed dataset is typed, or? No subtypes per table depending on data. Regards Thomas Tomiczek THONA Consulting Ltd. (Microsoft MVP C#/.NET) -----Original Message----- From: Ben Kloosterman [mailto:[EMAIL PROTECTED]] Sent: Donnerstag, 10. Oktober 2002 03:52 To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Strongly-Typed DataSets vs. Strongly-Typed Collections Hello again , more inline You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
