Hi Tony, You've nailed it. Typically you'll have some kind of validate method(s) on your business objects. If the validations are simple and/or unique, you could just implement the validation code within the business objects, but you'll probably find over time that implementing some kind of validation bean for re-usable validation will keep your code DRYer in which case you'll probably want to inject your validation bean(s) into your business objects so they are still responsible for validation but delegate the implementation to a library.
As for injecting beans into transients, it is a perfectly valid approach and one you should play with. In general the service layer approach is very J2EE'y and business objects handling (via composition) their own persistence is something you'll see more in the Ruby world. It really comes down to preference. I personally find User.save() an idiom I prefer over UserService.save(User), although in practice if you need to support remote method calls, you're probably going to need a UserService.save() anyway. One thing I will say is there are a number of times where it is extremely useful to be able to inject singletons into your business objects, so I'd definitely have the tool in your toolkit! Best Wishes, Peter On 12/3/07 3:47 PM, "Tony G" <[EMAIL PROTECTED]> wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
