And that really is what it comes down to... patterns and OO are really all about maintainability and as long as you don't jeopardize that, it really doesn't make any difference how you do it. Some things save time during development, but more dev time is often less of a consideration than long-term maintenance.
I agree with Brian that it's easy to lose sight of the funamental goal of all this, which is to say that the point is less doing things "right" by some arbitrary standard and more making sure that the pro- maintenance concepts like encapsulation, composition, DRY and the separation of concerns get applied for the long-term health of our applications (and our sanity!) Laterz, J On Dec 23, 2008, at 12:25 PM, Brian Kotek wrote: > One additional note, that even if you go the route of having the > DAO referenced from the bean, if you have an abstract superclass > method that actually does the save within the bean (i.e. super.save > ()) and you later decide you want to use the service instead, your > life is easier because the change of target is encapsulated in that > method rather than all of your concrete beans. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
