Monday, July 23, 2007

Force Fixing

I talked earlier about using enums for things like datarows returned from the database. Well, as you might have guessed, if I change what I return from the DB, my app will break. I've had many arguments about this sort of behavior and whether it's better to hard code the metadata from the DB or soft code it (meaning use reflection or other tools to determine what has been returned and handle it accordingly). I had a fairly long debate with Eric about it.

Obviously, as with every design situation, think of what you're doing first! Don't blindly follow a pattern. My coworker Joseph just transformed 500+ lines of code to 12 using reflection and soft coding. Was this a good move? Yes, because the code is still readable and manageable. I don't have the code here, but basically he checks the data's name, then finds the textbox with the same name, and puts the data in the box. Even in his iteration, there is some hard coding.

The point I'm getting to is that the main point people mention as a con to hard coding is actually a plus in many cases; being forced to fix the hard-coded stuff when you change what it's coded to. Before you say "WTF Ed!" let me say this; I'm not advocating highly-coupled design. However, I am advocating coupling your data controller classes/code tightly to your database. That way, if you (or someone else) changes your database, your code will fail, and you are forced to fix it.
Post a Comment
All rights reserved. Take that!