Thanks, Peter, that does make me feel a bit better about how I was approaching things. I have a couple of questions: when you talked about composing validation within business objects, were you referring to injecting in a validation object? Right now I just have a validate() method in my beans. I guess the approach to take depends on how much you want to abstract away or reuse your validation routine. Also, in the last part of your reply you mentioned the "Me.save()" method being delegated to a service or DAO -- you mean it's acceptable to inject services or other singletons into your business objects? I didn't even consider that option. (I always thought your singletons should only be called by a controller). Of course, I understand that it doesn't make my beans any smarter, as you pointed out.
On Dec 3, 2:51 pm, Peter Bell <[EMAIL PROTECTED]> wrote: > Anything to do with persistence isn't really about how smart the object is - > it's a separate concern, so yep, if all your object does is hang around, > update values and get saved to the db, the object will be pretty dumb as it > really doesn't have that much to do. You might want to look at composing > validation within your business objects for validating things like a strong > enough password, but it's true that simple CRUD apps generally don't have > the smartest of beans. What you want to avoid is lots of code in the service > layer that says "get A, B and C from user and then do something to them" - > instead you'd just ask the user bean to do whatever you wanted with A, B and > C. For simple CRUD that often isn't relevant. > > As a side note, I happen to like to be able to ask the bean to do things > like Me.save(), but I delegate that either through a service layer and/or > directly to an injected DAO, but that isn't making the bean any smarter - > it's just a different convention for accessing your CRUD features. > > Best Wishes, > Peter > > On 12/3/07 12:51 PM, "Tony G" <[EMAIL PROTECTED]> wrote: > > > > > 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 -~----------~----~----~----~------~----~------~--~---
