I need a bit of clarification. My goal is to not get sucked into writing an "anemic domain model". I want my business objects to have behaviors and not just delegate everything to the service layer. However, I'm finding myself putting more domain logic than I'd like to into the service layer, and it seems to be for one simple reason: a lot of the behaviors that I'd LIKE to put into my business objects involve database queries. I always assumed that SQL should only reside in DAOs and gateways. And since my service layer is my facade to these persistence objects, a lot seems to end up there. For example, I'm writing my first OO CMS. When a user updates a page, I'd like to be able to call the page.update() method or when a user changes her password, I'd like to just say user.changePassword(). But both of these end up being in the DAOs, and get called via the service objects. So, am I missing something here or is it normal to have a lot of dumb business objects if a lot of your app is basically CRUD?
-Tony --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
