Hi Chris, The service model is intuitively more attractive to me and it is how I'm currently doing things. I also see how a coder like myself with limited OO experience would prefer this approach even if it wasn't better, so I'm trying to "get" the underlying arguments from both sides.
I completely agree that MF calling my domain model anaemic is not very important. What I'm trying to do is to elicit the relationship between the different approaches and stuff like separation of concerns, cohesion, loose coupling, DRY, etc. which ARE important in terms of maintainability (everyone also says reusability, but I'll believe that when I see it in practice!). My view on an ActiveRecord is that it would simply call a DAO, so at least it doesn't have to speak SQL. However, from a separation of concerns perspective it is a reasonable question to ask as to whether an object should have to know ANYTHING about how to persist itself (including that is has a DAO). But then if an object doesn't know anything about persistence, what does it know about? I don't see the point in dumb beans. If I have a bean that is purely comprised of getters and setters and I don't plan to add logic to any of them, why not just pass a struct or single record query? So, what I'm trying to do is to get a sense of what an object MIGHT know about. Does a bean know about validations, transformations, calculations? Does anyone have any good reference applications with rich object behaviors that they think are good examples. I've been digging through all of the CF reference applications I can find and have not found any examples with non-trivial objects. Any ideas/opinions or random mutterings much appreciated! Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Scott Sent: Wednesday, June 14, 2006 8:12 PM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Model or View? I think that the discussions that Martin Fowler has raised in his post about the 'AnemicDomainModel' are definitely quite interesting, and by all means worth investigation, but I really think it should be taken with a healthy grain of salt. If you find yourself struggling to figure out how to add domain logic to beans/TOs/VOs just because your worried about this concept of Anemic domain objects, you really may just need to take a break and stop listening for a while, and just look at your architecture and see if it feels correct. I personally don't really like the concept of ActiveRecord, I feel it mixes data tier objects with business objects, which makes changes to persistence implementations more difficult. But if we are to buy this idea that the AnemicDomainModel is an antipattern that we need to fear, then we shy away from the service, domain object, DAO, DGO/ Gateway pattern, which I personally feel is cleaner and far more versatile. Of course, it took 10 years to come to the point where I felt that the service layer approach works the best for me. Just because it is a hot topic in the CF community certainly does not mean that anyone should blindly adopt this approach either. Do what's best for your company, development team, application, etc... Just thoughts, Chris Chris Scott [EMAIL PROTECTED] http://cdscott.blogspot.com/ http://www.coldspringframework.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
