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.
4 comments:
I do understand the service that hard coupling provides, and the sanity it can bring to a software system maintained by many developers, and a database shared by multiple apps.
I guess it just really troubles me to see the idiosyncracies of scaling software through a company informing the software design in a fundamental way. In the ideal world, you design the software in the "rightest", purest way and then make the business processes work around that.
I know that seems like it can't possibly work in a large software development environment. And in a lot of places, it probably can't. But I think we should at least view it as a necessary evil in large environments, and not as a best practice for software that runs over databases.
We're coming at this problem from different angles, based on the environments in which we work. However, I believe in the value of database coupling in single-developer single-environment projects as well as larger projects.
When I work on my own code, code that I alone maintain with data I alone touch, I still prefer to couple my controller classes to the database schema. Why? I want to make sure my changes happened. Good unit tests can make sure the code changes are valid, but they can't check the DB. Good integration testing with a test DB will catch bugs with DB/code coupling, but that happens after you build and release to QA. I want something as quick as unit tests that works.
Also, you're a butt.
I can understand the benefit you're getting from it -- but for me, it doesn't outweigh smaller, simpler code. If I mess up and don't actually perform the DB changes I thought I did, I'll pay the penalty of finding it out at a less convenient time.
To me it sounds like you're advocating writing code designed to look out for its author's human error. I don't have it in me to reduce my code's elegance for that.
Incidentally, I was recently made aware that you're a genitals.
Post a Comment