To potentially oversimplify the issue, I'll go out on a limb and say that unless you *are* using something that generates your DAO(s) for you, having a single generic DAO seems like a maintenance nightmare to me. I envision (particularly with your last point below) a maze of conditionals or switches that to me only gains you the ability to say "but I only have one DAO!" That's one big rule of thumb for me--if the conditionals start becoming overwhelming, then you're trying to do too much in one place. Or another consideration would be if you do have a single generic DAO that's parameterized to the nth degree, what effect does that have from a maintenance and debugging standpoint? The SQL would still have to exist somewhere, so if in your DAO's create method you're having to do something like have a case statement for each type of object, that seems like a bad idea to me. The end result is that you're shoving what by all rights (in my mind) should be in discrete objects into a single object, so I dont' see what you gain.
Just throwing some additional thoughts out there. I personally like having separate DAOs that are singular in purpose and I'd question what the real benefit of having a single parameterized DAO would really be given the fact that you'd still have to implement all the SQL yourself unless you use something like Reactor. Matt On 5/30/06, Peter Bell <[EMAIL PROTECTED]> wrote:
Hello Matt, Caught out! When brainstorming something I tend to stir up a bunch of information, skim everything and then reflect at leisure. I hadn't read the article all the way through *blush*. You're right. This article is more about wrapping hibernate with a typesafe interface which is not terribly interesting. The intent actually IS to have a completely generic DAO. Brian Rinaldi pointed out offline that this is effectively what Hibernate and Reactor already do (although Reactor actually generates the DAO's but at least there is no hand coding). The interesting question to me is how much of the service and DAO layers are repetitive if you parameterize out entity properties, field properties, business rules, transformations, validations and calculations. First step is to make all entities use a single generic parameterizable DAO. Next logical step is to allow each entity to use a single generic parameterizable service cfc. Wondering if the final step is just to load a bunch of entity properites into the system at runtime and to have a generic engine allowing you to do most anything to most any well desribed entity and to just skip the programming entirely for 99% of functionality!!! Not sure the final step is good for so many reasons, but I would be interested to hear from anyone else who's trying to parameterize out most of the variability in service layers and to use a generic object to handle all of the common flows (you know, the "if form returning, validate. If valid do X else redisplay form with returned error messages" kind of stuff). It seems a trivial amount of reusability, but as you start to add more sophisticated workflows, to generically treat forms as wizards when noofpages =1 and you put in intelligent parameter checking (especially against user inputs), even if each of those was abstracted to its own object, I'm just wondering if we really need to write that code for every single entity . . . Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Woodward Sent: Tuesday, May 30, 2006 11:23 AM To: CFCDev@cfczone.org Subject: Re: [CFCDev] FW: Maintainability vs. reusability? Did you take a look at the actual use of the "single" DAO? There is a single generic DAO, but there are still domain object-specific DAOs involved that are cast to the generic DAO type, I'm assuming just for ease of use within the factory pattern that's involved here as well. As you can see the "A usable Generic DAO" section he uses a factory to get a Person DAO, then comments "this should be injected" which you would accomplish using something like Spring or ColdSpring. This seems to be mostly done for typing purposes in Java but if you don't want to bother with this in CF of course you don't have to. I just wanted to make sure the intent wasn't to attempt to create a totally generic DAO as opposed to having DAOs for each domain object, which isn't what this article is describing (as near as I can tell). On 5/30/06, Peter Bell <[EMAIL PROTECTED]> wrote: > > > An update. Any thoughts on using single DAO as per: > http://www-128.ibm.com/developerworks/java/library/j-genericdao.html > > 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 > > > > -----Original Message----- > From: Peter Bell [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 30, 2006 10:46 AM > To: 'CFCDev@cfczone.org' > 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 > > > ---------------------------------------------------------- > 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 -- Matt Woodward [EMAIL PROTECTED] http://www.mattwoodward.com ---------------------------------------------------------- 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
-- Matt Woodward [EMAIL PROTECTED] http://www.mattwoodward.com ---------------------------------------------------------- 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
