Hi Steve, Many thanks for the link. I'd actually skimmed the page months ago but hadn't made the connection. I see you include data structure functionality along with the CRUD features. Interesting approach - will definitely play around with this. I had something similar back in my procedural code, but it is good to see an OO example of a way of implementing this.
Thanks again! Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Bryant Sent: Tuesday, May 30, 2006 11:09 AM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Maintainability vs. reusability? Peter, I'm not sure this directly addresses your issue, but it seems related to me. I ran into this issue a while ago myself. DAOs seemed for my situations to be more work than they were worth. I ended up creating a component to handle common database interactions (updates and inserts). For me, this has worked very well. I find that I get much more flexibility by using a component that I can pass around (composition, I suppose) than by using one that I can extend. I think that extension in this case will reduce your flexibility and add more dependency. One advantage that I have found to composition in this case is that my component can still extend another component with which it is a true ("is a") relationship. I have found this approach to be a good balance (again for my projects) between reusability and maintainability (but perhaps I am missing the point somewhere). Anyway, my component is free and open source if you want to try it out (the first presentation is actually the best introduction to DataMgr - apologies for the sound quality): http://bryantwebconsulting.com/cfcs/ Thanks, Steve Bryant 918-449-9440 Bryant Web Consulting LLC http://www.BryantWebConsulting.com/ http://steve.coldfusionjournal.com/ At 09:45 AM 5/30/2006, Peter Bell wrote: >Two of the biggest benefits of OO design are maintainability (code >that is easy to update) and reusbaility (components that are easy to >reuse). Many OO design choices help both, but in most companies, one >is more important than the other. If you're a job shop churning out >5 new projects a month, reusability is more important than if you >are a product company that will only ever build and maintain one web >application. > >For instance, loose coupling and a small number of dependencies are >important for maintainability but even more so for reusability (who >wants to have to drag 20 objects across just to reuse an >AddressService or AuthenticationService?!). So, what happens when >maintainability and reusability collide? > >For instance, I'm considering pulling all of my SQL into a base >class or seperately called object. However I implement this it will >decrease reusability as I'm adding a relatively tightly coupled >object dependency to all of my services. On the flip side, if I want >to wrap transactions around queries, add metadata to all queries >(lastupdateddate, etc.) or make any other universal change, I only >have to change one set of queries which is then wrapped by all of >the entity specific methods which simply pass the necessary >parameters to the underlying method. > >And so to the questions: >- Is anyone else thinking about distinguishing between patterns that >primarily improve maintainability vs. reusability (I know that most >of the time they improve both) >- Any good for/against arguments to having just a SINGLE DAO rather >than one per entity, with the service methods just parameterizing >and calling the single DAO (assuming sufficient flexibility can be >programmed into the system in a performant manner). > >Any thoughts much appreciated! > >Best Wishes, >Peter > > >---------------------------------------------------------- >You are subscribed to cfcdev. To unsubscribe, send an email to >cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the >subject of the email. > >CFCDev is run by CFCZone (www.cfczone.org) and supported by >CFXHosting (www.cfxhosting.com). > >An archive of the CFCDev list is available at >www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
