The Myth of “One Place to Change”
November 21st, 2007
According to the discipline and punish link blog entry:
Except putting schema code all over the place tends to be a recipe for spaghetti. The benefit of Repository classes is there’s only one place in the code that has to change when your database schema changes.
Yeah, right. Based on my experience, when the database changes, it is because you need to track some new piece of information, and that inevitably ripples through every layer, all the way to the GUI screen where you now need something like a new text field to enter the data.
Nice theory, but I don’t think you see that kind of utopia all that often.
I see it all the time during the prototype/initial development stages for new services. It’s also pretty important to have a single place to look for all JPA/HQL queries related to a specific subsystem. When you have such queries scatted through your domain classes in the case of “transparent persistence” it ends up being a very tedious to find what you’re looking for.
Maybe you see it during prototyping because none of the other layers exist yet?
ouch…
I’m really just taking issue with this extraordinary claim: “there’s only one place in the code that has to change when your database schema changes”. I hope some other people weigh in on this, because it sounds very unrealistic unless you only deal with greenfield apps.
Where I work, with hundreds of customers and decades of legacy to deal with, adding new information to the database means adding new fields to the UI, new online help, new validators, new business rules, updating custom Crystal Reports, updating COBOL batch jobs, etc. It can be catastrophic.
Who are you anyway? Billy Ocean? Ted Neward? You should get a gravatar.
I have to say that I agree with you on this.. I’m struggling to think of a situation where *only* one place had to change when the schema changed. It always ends up making its way to the UI, new screens/fields/columns etc.
Maybe what they mean is that only one place *must* change, but the other places have the option of changing. How useful/applicable this is depends on your application. Maybe if there’s a bunch of back-end calculations going on..
Yeah, I don’t buy it, either. Had to add support for a new column on an existing table today (yeah Thanksgiving deadlines, baby). Had to change two Struts Actions classes (the add and the edit), the XSLT to handle the new selected column value from the new drop down list it will populate. Had to change the business class to add the attribute with its accessors and mutators, etc….
Not even the best design is going to keep you from having to change multiple classes with a practical application, IMHO.
Maybe I’m numb to it, but changing all these classes wasn’t the end of the world, and I wrote tests to improve my confidence that the changes I made to accommodate the new column didn’t break existing code. It can always be worse ;-).
I have to agree. Once you make a change to the database schema, more likely then not, you’re going to have domino effect propagate all the way to the UI. Depending on your architecture, this can be affect a large amount of objects. Of course, to the requester of the change, it’s just one field
When I say one place to change I am really talking about one place to change things related to the database specifically validation logic and JPAQL queries. Of course extensive changes to the schema will change the entire app. Maybe it’s just me, but I’ve dealt with applications where “schema logic” (mostly in the form of EJBQL) was scattered throughout the codebase (to be more “object oriented”) and it was not fun at all. So yeah, these days I stick all of that in one place, a Repository class.
“Had to change two Struts Actions classes (the add and the edit), the XSLT to handle the new selected column value from the new drop down list it will populate. Had to change the business class to add the attribute with its accessors and mutators, etc….”
This doesn’t round right to me. Action classes ought to carry the business object itself just so if the business object changes the Action shouldn’t need to. If the interfaces between your layers are coarse and generic enough it should be possible for all types of changes to pass through without disturbing other layers — until you reach the GUI at least.