True but the whole idea of XML is so it is easy to communicate with other systems . Just send them the XML and let them use it as they would and other piece of data. Nobody would write a Java version of a Dataset nor do you need to - just send the XML back.
This works well with clients and partners. If you are designing a diverse system a custom collection is a must - but anyone is mad to design there won system. Ben -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Chartier Sent: Tuesday, 8 October 2002 4:43 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Strongly-Typed DataSets vs. Strongly-Typed Collections Another thing to consider..which im sure im not the first to mention it, is how is this very complex xml which the dataset generates hindering integration with non-.NET systems? Something as simple as classic VB (STK 2/3) attempting to consume the standard .NET "DataSet service" would be tiresome. Especially if that service expects the data set back to provide a list of changes (diffgram...?). I would hate to the the non-.net programmer that had to implement the DataSet functionality, etc.. And wouldn't the integration with a more slimmer-easier/understand to use "Collection service" facilitate the integration? .just some thoughts. -----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED]] On Behalf Of Philip Nelson Sent: Monday, October 07, 2002 9:38 PM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] Strongly-Typed DataSets vs. Strongly-Typed Collections > Since now it's easy to make/use a collection for databinding, I guess > most of the reasons for using a dataset are eliminated. > It sure would be nice to see if a DataSet is significantly worse than a collection. When you think about it, and given an axiom I really believe: "premature optimization is the root of all evil", I would like to think choosing a DataSet first is the right choice. If in some application you discover problems because the number of simultaneous occurances causes a memory bloat, or massive cpu ticks are needed to create and tear down your datasets (if it's proved that datasets are worse), the worst that can happen is that you refactor and use a custom collection. In the meantime, one less block of code to check into source control, one less library to maintain, one less skill to teach junior programmers, etc, etc, etc... You would want to do as similar comparison as possible, one simple table with one column, strongly typed, rows added at runtime, enforceconstraints off and the like. __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.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. You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
