An
update. Any thoughts on using single DAO as per:
Also,
in general terms don't people find they're copying a lot of code with entity
specific services? Don't most of your %EntityName%Service.cfc's
(UserService,cfc, ArticleService.cfc, ProductService.cfc, etc.) has extremely
similar methods and flows (for handling returning forms, validations, etc.). I
wonder if there wouldn't be value in just parameterizing what changes and using
a single base (or seperate) service class for handling transformations,
validations, saves, get lists, get instances, etc? Is there really a compelling
reason to have code (as opposed to parameterization and calls of a generic
method) when the things we do to so many entities are fundamentally so similar?
Any
thoughts much appreciated!
Best
Wishes,
Peter
Peter
-----Original Message-----
From: Peter Bell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 30, 2006 10:46 AM
To: '[email protected]'
Subject: Maintainability vs. reusability?
From: Peter Bell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 30, 2006 10:46 AM
To: '[email protected]'
Subject: Maintainability vs. reusability?
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
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]
