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
[email protected] 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/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] 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/[email protected]
