An Architect's View

Following on from the CFCDev thread I mentioned about factories and ColdSpring yesterday, I noticed Scott Barnes railing against using DAO / Data Gateways in ColdFusion and left him a comment saying I felt he'd missed the point. In fact I was a bit mystified by his entire post. However, reading Joe Rinehart's blog post today about anemic domain models made me realize what bothered me about Scott's post. Joe's point is that we're seeing a tendency to separate simple applications into tiers in such a way that our domain model - the real business part of our application - no longer does anything useful. I think Joe's example is slightly misleading tho' because it is too simple to underpin the point I think he is trying to make. Here's the rub: most of our day-to-day ColdFusion applications are simple data entry stuff... display a form, user enters data, create a new entity from the form data... display a list of entities, user selects an entity, display pre-populated form, user changes some data, update the entity from the form data... we have an anemic domain model because, well, the domain model doesn't actually have any behavior! Our controller loads beans to pre-populate the form and updates beans from the form data and persists the data. There's no behavior there. Our bean isn't smart - at best it might do a bit of validation for us. The controller isn't doing much either beyond orchestrating the CRUD operations on the bean. We're caught between a rock (an example simple enough to explain in a few sentences) and a hard place (an example complex enough to show why we might use these patterns at all). No wonder some folks try to use these patterns (in simple apps) and can't see the point of it - and it can be hard to take the advice on trust that it's worth it for when your app grows. Perhaps we need more KISS (Keep It Simple Stupid), YAGNI (You Ain't Gonna Need It) and XP-style refactoring? Download my frameworks presentation and the accompanying code examples (see "Software" pod on my blog) and look at the first five variants as a progression from procedural to simple OO to refactored OO and see how it sits with your comfort level for such a simple application. The fifth variant has an anemic domain model because the domain is very simple - but consider how much easier that version would be to use as a basis for a much more complex task management app than the fourth variant.... Thoughts?