Drawing Boxes and Line with the DataSet designer
One of the neat things about working on Visual Studio is that it is such a big and rich product that I’m always being clued into both new interesting features and old features that I have just missed up until now. I was recently working on some squarified treemap UI prototyping and I was coding up a DataSet to hold the basic data for my view. I don’t have any ADO.net experience so I was just pulling stuff together with the MSDN entries for DataSet, DataTable and DataColumn open in a few IE windows. After asking a question about table relations of a colleague of mine, he pointed out to me that Visual Studio already has designer support for DataSets and suggested that I take a look at it.
A lot of my fellow team members (and a lot of programmer in general) are pretty down on the idea of designers. They roll their eyes at the thought of some programmer in the future (probably using some type of Minority Report style goofy 3D input device ;) ) connecting little boxes with lines to somehow magically create fully featured applications under the surface. And to be honest, they have some pretty good points; we are certainly a long way off from designers becoming some kind of programming mainstay. But in my experience, designers have been making some great improvements over the last few years. I’ve found them useful in two particular scenarios. First, they can be useful when you do not have experience in the designer domain and they can help guide your design. And secondly, they can be useful when they are restricted to a small set of the overall application. For instance, UI designers have been catching on recently not only because UI lends itself to visual layout (and it does), but because it’s looking at a small subset of the total application code.
The DataSet designer does meet both of the above criteria, as I am not experienced with datasets and it is dealing with a restricted subset of the total application code. So next I’ll show you a quick walkthrough of how I used the DataSet designer in my application. Adding a new DataSet designer component to your project is as simple are right clicking the project, selecting “Add new item” from the context menu and then selecting DataSet in the screen shown below.
After creating the new DataSet you will have a new designer space opened up for you in your IDE (shown below). Also, you should have your Toolbox window open so that you can drag in the various components for your DataSet.
For my simple app, I have a started out with the TreeMapBaseData table that holds a bunch of information about commands that are being logged. Creating the table was a simple as dragging it from the Toolbox out onto the designer surface. For the columns I simply right clicked on the table and selected add new column. To edit values for the columns I used the property sheet shown below. By setting the CommandID columns to be unique = true it automatically showed up as the key column for my table as I intended (you can also add and remove keys from the designer).
My next step was to create the TreeMapCommandData table. My goal for this table was for each unique “Command” string in the TreeMapBaseData table to have a TreeMapCommandData row that stored the count of instances of that command and the sum of the execution times of that command. My first step was to drag on a new table and add the appropriate column names, with the “Command” column set to be the key by marking it unique. Next I needed to build a relation between the two tables. By selecting the TreeMapCommandData and then dragging a relation onto TreeMapBaseData I was presented with the Relation dialog box shown below. Since Command was the “one” in the one-to-many relation I set it as the parent table and linked up the “Command” column.
Now that I had my two tables and the relation between them defined the final step I needed for my DataSet was to define the sum and count columns for TreeMapCommandData. To do this I just added the appropriate expressions into the expression fields of the TotalExecutionTime and NumberOfCalls columns. For example the TotalExecutionTime column contained the following expression “Sum(Child(CommandRelation).ExecutionTime)” where CommandRelation was the name of the relation that I created between the two tables.
Now that I constructed the DataSet I was able to access all the elements programmatically through my code. For example I could replace a statement like:
myDataSet.Tables[“TreeMapCommandData”].Columns[“CommandID”];
with:
myDataSet.TreeMapCommandData.CommandID
Plus you get the free Intellisense support, which is very nice to have.
So in review I have pretty positive feelings about using the designer to create my DataSet. I’m sure that if I was a veteran ADO.net guru, I would probably find it more annoying, but for a novice it was a pretty sweet tool. This quick example is probably the best experience I’ve ever had with a designer, perhaps there is some hope for connecting boxes and lines in the future after all ;).
Comments
Anonymous
October 24, 2005
The comment has been removedAnonymous
November 16, 2005
I'm just curious at your overall approach to the design.
When starting with a data designer such as this, or straight SQL, the design is very data centric. Do you find you took this approach because you had a data-centric design in mind? Is there any reason you didn't go with an OO approach? If you were to go with an OO approach how different would it look? Finally, what tools would you have used if you started with an OO design?
These are the questions I'm struggling with as of late. I prefer to design using OO techniques, but ultimately all the data I deal with is stored in a database, so ignoring a data centric design approach isn't practical.Anonymous
June 09, 2009
PingBack from http://insomniacuresite.info/story.php?id=4191Anonymous
June 18, 2009
PingBack from http://thestoragebench.info/story.php?id=1413