>-----Original Message----- >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.
Just to add my 0.02$: the biggest usual headache in code maintenance or debugging (which are often the same thing) is figuring out what change needs to be made where, as opposed to actually making that change. You *may* occasionally immediately see that you need to make a relatively simple change across a vast vast number of files, but that's pretty rare: you will usually be staring at the code with a blank look on your face, trying to figure out how it's supposed to work, why it isn't working, and what you need to do to change that. Usually with the boss and or the client breathing down your neck. Moral: keep your code as simple as you possibly can and never do something clever for the sake of being clever... especially if it makes the code harder to understand. As much as possible, two peices of code that solve similar problems should use similar solutions, so that time spent understanding one of them pays off in understanding the other. In short: optimize for readability, not writeability, because you will read your code much more often than you will write it. To get back onto the topic at hand - many small, simple, and similar DAOs are easier to understand than one big "God" DAO - especially if the relationship between a business object and its DAO is very easy to grasp (naming convention, packaging, etc. If you use ColdSpring, even better). If you find that you are copying and pasting large blocks of code between all of your DAOs then there are solutions like inheriting from a BaseDAO or just cfincluding the common code which can help you out /t ---------------------------------------------------------- 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]
