Comments on: The Myth of “One Place to Change” http://stuffthathappens.com/blog/2007/11/21/the-myth-of-one-place-to-change/ Technology and Geek Stuff by Eric Burke Tue, 24 Aug 2010 19:55:26 -0400 http://wordpress.org/?v=2.8.6 hourly 1 By: ocean http://stuffthathappens.com/blog/2007/11/21/the-myth-of-one-place-to-change/comment-page-1/#comment-2071 ocean Tue, 27 Nov 2007 19:45:16 +0000 http://stuffthathappens.com/blog/2007/11/21/the-myth-of-one-place-to-change/#comment-2071 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. 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.

]]> By: JR http://stuffthathappens.com/blog/2007/11/21/the-myth-of-one-place-to-change/comment-page-1/#comment-1873 JR Fri, 23 Nov 2007 19:42:04 +0000 http://stuffthathappens.com/blog/2007/11/21/the-myth-of-one-place-to-change/#comment-1873 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 :) 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 :)

]]> By: Smitty http://stuffthathappens.com/blog/2007/11/21/the-myth-of-one-place-to-change/comment-page-1/#comment-1845 Smitty Fri, 23 Nov 2007 07:08:39 +0000 http://stuffthathappens.com/blog/2007/11/21/the-myth-of-one-place-to-change/#comment-1845 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 ;-). 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 ;-) .

]]> By: denise http://stuffthathappens.com/blog/2007/11/21/the-myth-of-one-place-to-change/comment-page-1/#comment-1835 denise Thu, 22 Nov 2007 23:36:37 +0000 http://stuffthathappens.com/blog/2007/11/21/the-myth-of-one-place-to-change/#comment-1835 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.. 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..

]]> By: Eric Burke http://stuffthathappens.com/blog/2007/11/21/the-myth-of-one-place-to-change/comment-page-1/#comment-1793 Eric Burke Thu, 22 Nov 2007 03:47:20 +0000 http://stuffthathappens.com/blog/2007/11/21/the-myth-of-one-place-to-change/#comment-1793 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. 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.

]]> By: ocean http://stuffthathappens.com/blog/2007/11/21/the-myth-of-one-place-to-change/comment-page-1/#comment-1790 ocean Thu, 22 Nov 2007 02:36:48 +0000 http://stuffthathappens.com/blog/2007/11/21/the-myth-of-one-place-to-change/#comment-1790 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. 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.

]]>