I've been playing about with LLBLGenPro's Object Data Source recently.
Mostly because I want to know if it's the sort of thing which could actually be used in a commercial project, or whether it's not quite all the way there yet. In my experience, working with GridView style pages goes one of two ways:
- They're simple, basic CRUD type operations. Maybe some sorting and/or paging.
- They're so insanely custom that you might as well have written your own control and not even used a GridView/Repeater.
I'm looking at LLBL's Data Source for the occasions which fall into option #1.
So far, it's looked pretty useful. You declare your data source, link it to your GridView (or whatever), and away you go. You get basic CRUD operations against your model data without needing to do anything other than use declarative programming. There's something nice about staring at an ASPX codebehind file which is totally empty (on a page which actually does something of course). And it saves time. For the simple pages (basic admin pages are a good example, reference data and the like) it's a great way to save time, and to save developers going insane writing the same sort of code against different model data. It's also good in the sense that it leverages a feature in a product you've already purchased, and puts means you're using code which has already been through a lot of testing and other such QA processes. You can also wire in custom events if you want, so the option of adding business logic and extending beyond basic CRUD operations is there if you need it.
None of which is the topic of this post. This post is simply here because I've been pondering over something on and off for the past few days which simply wouldn't work, and I promised myself I'd write about it when I found the problem because it was so annoying. So here we are. We really must stop meeting like this.
Problem: When using an LLBLGenProDataSource2 (I roll adapter styles) with a GridView the data is bound correctly, but all updates fail. Everything appears wired up correctly, in fact the code could have been copied from another page in the same solution and simply been pointed at a different entity in all the right places.
Solution: The DataKeyNames property of the GridView was set to 'ConfigurationID'. The fieldname in the database was 'ConfigurationID'. I changed the DataKeyNames property to 'ConfigurationId' (note the case of the last character), and all the updates started working.
Reason: LLBLGenPro converts all properties of it's generated entities into proper Camel Case, so the property on my entity was actually 'ConfigurationId'. The DataBinder is much more forgiving here, so you'll see values in your column regardless of your case. You can use alternating l33tspeak if you like such as coNfIgUraTiOnID and it'll still work. L33t! However the DataKeyNames property isn't as forgiving. It needs to match the casing of your generated entity, and not your source database.
Why is it that problems around casing are so common, so simple to solve in terms of work required, and yet often so hard to find?
What was also most interesting here, is that the positive point I just mentioned in that there's no code at all ended up being part of the reason this took so long to debug. There's nothing to debug! I simply sat there staring at the database schema and the various ASPX declarations going "THEY'RE THE SAME! WHATS WRONG!".
Sometimes part of being a good coder is knowing when to walk away from a problem. And so spending 10 minutes on this each night for a few nights has worked out well in terms of reducing the frustration factor.