Data Browser - Viewing Site  Sector 23 Code Bank Logged in as:  Guest  


DataBinding in .NET 2.0
This is the first in what will probably be hundreds of such ramblings.... you see, DataBinding in .NET 2.0 is too easy; or at least, it's supposed to be.
While it is in principle possible to continue doing everything the way you did in .NET 1.1 (with sql and classes and tons of code), the idea apparently is that instead of writing code to manage your data, you call "automatically generated functions" which were created via "drag and drop" to get/set data.
The first problem is that these are generated based on your selected database/objects you want to update. As soon as you add a column to your database, for example, you have to go back and regenerate the objects for it to show up. At first, this was confusing, because I couldn't for the life of me figure out how to modify the existing objects once I'd updated the datasource.
Basically, you go to the 'DataSources' explorer (menu: Data-> Show Data Sources) and then open the Edit DS with designer, and play around with all the right-click 'configure' options and property windows. The controls on your form have the property (DataBindings) at the start of the properties list for you to point back at the datasource. (which is a *YourNameHere*BindingSource auto-generated class).
You also get a *YourNameHere*TableAdapter (which you fill with a datasource, which happens to be a *YourNameHere* Object. The whole thing is rather confusing, and it's not clear at all (without much poking around in hidden code) what all the bindingsource/object/adapter/etcs actually do.
When you're done setting everything up (Everything! Even binding combo boxes is done almost entirely using the browsers), I guess you call the TableAdapter.Fill on a source (which you get from the objects), modify the contents of the UI, and then call TableAdapter.Update(source). It does the rest. There's also an Insert and Delete, but those are automatically handled by default (again) using another automatic control, the BindingNavigator.

Anyway, in summary, you end up with 4-5 components sitting on your Form that were generated using wizards and properties windows that handle everything but the actual data entry. (the keystrokes that the user enters... now THAT would be something special).

Now here's the part I'm restless about. First... if one of those properties/methods is accidentally set wrong and something throws an exception, instead of tabbing through your 'load' method to look for something that doesn't look right, you are stuck with no idea which one of the hundred 'auto-generated methods' is breaking. And this isn't a matter of just hitting F11 through em all. I mean, sometimes it's not clear where ANY of them are, to start the first breakpoint. Maybe there's a way, but I tried 'break all' and it skipped anything that was 'auto generated'.

Second, I can't figure out how you're supposed to customize anything. Let's say you bind textboxName to 'name'. Now let's say you ONLY want to bind it to name if flag1 is true, else bind to 'city'. Ummmm the properties for the databinding don't have any logical operators in them. I assume that in my code, I can clear it and rebind it? If so, why set it in the first place? I'll have to do some testing on this one.

Third, all the SQL code is hidden deep in 'uneditable' designer files. This means that if you want any logic or business rules, they need to be at the object level, or the UI level, or the 'Save/Update' level, etc. Obviously, this is best practice... you should NOT be putting business logic in SQL statements. However, the fact of the matter, is that now your SQL code is now only editable through the little designer windows. Finding and editing SQL is no longer a matter of looking in your classes (unless you turn off the SQL generation, which I'm considering) for the appropriate method. Now, you have to pretty much make sure that your select statement is simple enough so that the updates and deletes simply work.

Fourth, the designers are slow, complicated, and frequently crash. There's something about coding in notepad that has its advantages.

Nonetheless, the idea of having all my database-business-objects auto-generated (obviously I'm going to have to extend them to get the actual functionality I need) is interesting and somewhat exciting. The question then is, "do I trust that this all is going to work, and I'm not going to accidentally hit 'delete' on a Control on my page some day and lose thousands of lines of code? Or is it better to just code it all in the .cs file?"
Wish I knew... I'll update this when I've decided.

> > > > >

OK, after further testing....
When you first create the datasource, you have the option to save the connection string in a config file. Choose that, cause otherwise (as I had suspected), the connection string is hardcoded into your app forever. One problem solved.

What if the underlying datasource is gone/corrupt? Looking good... Visual Studio has everything saved in xml files, and lets you program away, not throwing an error until you actually try to pull data from the source.

What if you want to change stuff? Well, this is still mildly problematic. As long as you don't regenerate the whole thing or redo the wizards that created whatever you're changin, you can change as many properties as you like. To delete the 'source', you have to actually delete the DataSet.Designer.cs file (and all subfiles are auto-deleted). As soon as you recreate it, you're back to the .NET defaults.
And fortunately, while all this adding/changing/deleting is going on, your own source code (myfile.cs) is not touched at all. So you don't have to worry about .NET 'repairing' all your code while something is temporarily removed. Another worry gone away. It still midly annoys me, though, that all the properties you set in the designer are gone after it's deleted, but I suppose that's the behavior you get from any other Form Control... this one just has a LOT more properties.

Dynamic SQL: The fill and getdata queries the table adapters spit out require you to specify the columns as part of the 'Select Command'. If you are attempting to dynamically return a random set of columns (based on user needs, to reduce the size of the set), it appears that you have to ditch the wizard and code your own adapter/table filler, just as in .NET 1.1. I tried using 'exec' for a dynamic SQL and it informed me that it (and @declare) weren't supported.

Created By: amos 3/10/2006 8:40:34 PM