DAO's and gateways are a waste of time :-)
If I'm moving from procedural coding to object oriented development, I get the vast majority of the benefits from applying good Model-View-Controller separation, creating a service layer as an API to my model and writing rich business objects (IBO's of course!) to encapsulate my business logic.
Creating DAOs means that I have to do a lot of extra typing as I need to create CRUD methods in my service classes that just delegate to CRUD methods in my DAOs. Don't get me started on the whole DAO plus Gateway thing. We really don't need five beans for every business object - whatever Sean might have said in 2004.
I don't see why I should waste the extra time and typing. What do you think?
I am on the fence about the Gateway; yes, its not a "gateway" as it is defined in J2EE design patterns but I find it a nice way to organize my code. To me, its more a personal preference. That being said, a DAO is necessary because it abstracts potentially fragile database specific code into a class that is specifically designed for that purpose. Without a DAO, your query code ends up in your service or, even worse, your beans/business objects where it is more difficult to separate your business logic from a specific rdbms implementation.
But who cares?! When was the last time you actually took a live project and changed the dbms? I think that an abstract factory returning different DAOs for different dbms' may make sense for a framework author, but not for most projects. The goal is to encapsulate what varies and in my experience projects just don't change database systems often enough to justify the extra typing required when using a DAO.
Stick your queries in your service classes, write rich business objects and you get most of the benefits of OO.
True, I have never actually been tasked with changing code to support a new rdbms but you might move some data from an rdbms to some other form of persistent storage for a particular object. Also, as the database changes, adding columns perhaps, it is much easier to isolate those changes as they relate to queries. Lastly, I would argue that since DAOs are pretty generic and easily repeatable, it is very easy to simply generate the basic CRUD if you are so concerned with typing.
I don't buy the "some other persistent storage" as I don't know about you, but I don't usually have clients come back after I've built a site and ask me if I could persist to XML instead of a database. It happens, but not enough to justify preemtively doing the extra work. That said, there are some benefits that should be considered.
I agree with you that the separation of concerns is nice as it is easier to just go through a DAO to make all of your SQL changes, although you need to be careful about the way you write your DAO API so that you don't end up having to edit your service classes *and* your DAOs when you add a column to your schema.
Interestingly for me, the killer benefit of DAOs is the one that is seldom discussed by CF developers . . . unit testing. Without DAO's you can't mock out (slow) database calls and it is hard to write a good set of unit tests for regression testing your code. However, given the low adoption of unit testing in the CF world to date I'd still argue that many people who use DAOs don't get the benefits they should because they don't need to mock out their db interactions.
As you note, you probably don't hear much about unit testing because too many people (myself included) don't have any formalized unit testing process (sounds like fodder for another CFArgument). Also, I will agree that if it isn't done right, you can end up making changes to both your service and your DAO when you add a column. Still, you can't deny the benefits of something because many people don't necessarily do it right.
Well I could - this is the CFArgument not the CFAgreement after all!
To summarize, obviously DAO's provide benefit when used properly. I use them in all my applications and get a lot of benefits from doing so, but I would argue that many CF developers aren't getting a good ROI from using DAOs. If you're just starting out with OO programming I'd recommend focusing on MVC, Service classes and rich IBO's. You can then move to encapsulate your SQL into DAOs when you feel the need - either for separation of concerns or to speed up your regression tests.
I disagree. DAOs are probably one of the simplest aspects of OO to understand and to write (or generate) and thus aren't a real bottleneck to learning or building OO applications. If we both agree there are more benefits than drawbacks if done correctly, then its just a matter of helping people do it correctly.