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: '[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 ---------------------------------------------------------- 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]
-- Matt Woodward [EMAIL PROTECTED] http://www.mattwoodward.com ---------------------------------------------------------- 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]
