Put the knife down and take a green herb, dude.
One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com
Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!!
Back-up your data and, when you bike, always wear white.
MarkUpDown is the best Markdown editor for professionals on Windows 10.
It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support.
Features you won't find anywhere else include...
You've wasted more than $15 of your time looking for a great Markdown editor.
Stop looking. MarkUpDown is the app you're looking for.
|Friday, January 02, 2004|
As if the .NET datagrid wasn't crazy enough before, now there's someone whose entire site is dedicated to the monster... This page in particular, "A listing of Datagrid articles from other resource sites:", is pretty bad news. Nothing there but tons of datagrid articles.
[WARNING: Awfully long blog follows, mainly b/c I'm going to need to reuse this text (formaled up a bit) when I justify why I'm designing an awfully big system the way I plan to. Or I'll at least reuse the text in a post to microsoft.public.dotnet.framework.adonet]
freakinname talks ADO.NET and why the DataSet is overhyped
I'll admit, the whole ADO.NET set up perplexes me right now. There's a heck of a heck of a lot of effort in there to make distributed applications incredibly easy to make and maintain, but for your run of the mill system, I'm not sure what all this overhead gets you other than an unnecessarily complex object model.
Just as an example, let's say you have a system where you have tons of people out in the field, um, say surveying property parcels. You want them to be able to edit notes about plots, ownership information like phone numbers, contact address, etc, and maybe even add a few digital photos. You don't want them scrawling all this out on paper atop a clipboard, you want this to happen once, electronically, eliminating a data entry step from your current process (no clipboarded forms to rdbms back at the office). You do, however, want to maintain relationships between tables and generate unique keys for those relationships when adding new records and the like.
This requires a ton of overhead if you're dealing with, say, Visual Basic 6.0. You might have to hook up an Access database with all the entries your appraisers need when they're out in the field and you'll need to hack something to have all the information brought back in to your system once they're back. You'll need to keep track of primary key values, possibly replacing temp values from the Access file with truly unique ones generated by SQL Server or another rdbms. And you'll also have to check and see if anyone else has edited the fields the user in the field updated - even down to the tables your field user used to build relationships to new entries to ensure they're still valid.
ADO.NET has taken this task and made it much easier with its disconnected DataSets. The whole point is that DataSets are relationship-laden subsets of your data that you can take anywhere without having another hit to the main server. There's also a Guid.NewGuid method that will return unqiue strings that you can create on any computer, anywhere, and feel pretty confident you'll be able to use that as a primary key when you roll your disconnected DataSet back into your rdbms proper.
But other than when you're doing truly disconnected data manipulation (ie, you're physically taking the data away from the network where it's stored, at least for all practical purposes (a cell phone dial-in connection isn't quite the same as a 100baseT cable sticking out the side)), I really can't find - with certainty - more more than one reason to use a DataSet over the way I used to do it with ASP and vbscript. In ADO.NET, this translates to using the DataReader for pulling back data and using the [Sql/OleDb]Command's "ExecuteNonQuery" statement for INSERTs, DELETEs, and UPDATEs.
Examples like to show things where you've got, say, a forward and next button on a form that displays the values of one record at a time where each GUI element is databound to an element in your DataSet. But how did you decide what went into the DataSet to begin with? If we're, say, dealing with customer information (address, phone, etc), did you slap every customer in the DataSet before cutting your application loose? What happens if the user only needed to update one record and then move on from customers to orders? Now there's some overkill and wasted resources.
What, of course you didn't slap every customer in there? Just those with last name of "Smith", I'll bet. Well, you're getting close enough to having a user who only wanted one record, why not just pull that single record back? And if you do only pull one, what does a DataSet really get you? You can't sort one record. You don't need next and previous record buttons. You really don't need anything disconnected at all.
The answer why DataSets are still used is simple - overhead for updating. People would rather write code to databind than code to fill and parse results from individual elements that are later turned into SQL code. Why, I don't know, other than that's what the Microsoft wizards do for you. At this point, it really is a similar amount of coding to handle everything programmatically than to hook up validators and databinds for all the GUI widgets you have on the screen. I suppose perhaps you'd rather have a DataSet passed from your presentation layer to your data services tier to make your data services tier thinner, but now you've also got a pure data access object (the DataSet) mixed in with presentation code. Neither method is obviously better so far.
So why do it programmatically? Here goes...
1. Complete control over the 0s and 1s. Know what data is going where in your app, and be able to access data flow at any point in the process for more customization opportunities, whether they're needed or not.
2. Less overhead. VS.NET isn't going to be doing anything for you behind the scenes. This is similar to 1., but adds the fact that you don't have any extra XML (aka, "severely bloated ASCII useful only in totally anonymous logic sharing") filling memory with data values unless you actually want that data there (see for more freakinname XML-ige)
3. Most importantly, fewer new object models for your programming team to learn and maintain. KISS.
Which of course brings me to the single reason I can see to use the DataSet in an intranet .NET application - the "review and edit at once" function. Grab a datagrid, hook it up to a DataSet with every record that's, say, been entered in the last week. Not only can you review and sort using the DataGrid's top row, you can also modify the table(s) values right there in the grid, validate, and get ready to check back in. Not the best GUI, and certianly not award winning, but for quick, small edits to record values that are short (can be reviewed and shown in a small text box) which a user wouldn't be able to target with extreme accuracy before seeing all the values in front of them, the DataSet and DataGrid are perfect. ;^)
posted by ruffin at 1/02/2004 01:28:00 PM
All posts can be accessed here:
Just the last year o' posts: