@Barney. Thanks again for replying Barney. Your 1st response makes a lot of sense i.e. allow for things to be as re-usable as possible. I don't quite follow your 2nd response regarding ADM. I'll have to read up on this tomorrow. Hope you had a good sleep.
I'll have to keep playing / trying options. Perhaps some other experts will chime in with their experiences / knowledge. I'm sure there are numerous approaches hence why in my original post I threw the question out to everyone to share their views. Cheers Matthew On Oct 21, 5:19 pm, "Barney Boisvert" <[EMAIL PROTECTED]> wrote: > There's a bootstrapping problem though, because in order to validate > the email address with the User object, you have to have the User > object. But you can't get the User object until you've validated the > email and used it to pull the correct object out of the database. > That latter behaviour DEFINITELY does not belong on the User object > unless you're using an ActiveRecord-like design (which I don't care > for, but won't rail on too much). But that's a separate question from > an avoiding anemic domain model (ADM). > > ADM is about having your business entities DO stuff, but in a good OO > system, the only stuff an object doed is the stuff bound to the > object's state. In other words, static lookup methods and such (the > ActiveRecord stuff) don't count. They can be present, of course, but > they're not going to influence the anemic-ness of the model either > way, because they're not part of the model. Unfortunately the line is > somewhat blurry with CF since it doesn't have the concept of static > methods, but cest la vie. > > And please take what I've said here with a huge amount of loose > interpretationism. Nothing in these types of conversations can be > summarized in a few sentence without ghastly omissions of both edge > cases and background reasoning. Not to mention it's late, at least > where I am. > > cheers, > barneyb > > > > On Mon, Oct 20, 2008 at 11:09 PM, Alan Livie <[EMAIL PROTECTED]> wrote: > > @Matthew - I asking a question on password validation yesterday and trying > > to avoid the dreaded 'anemic domain model'. > > So when you say 'When a user login form is submitted should the service > > layer validate the email address (perhaps delegating this task to a UDF > > object)?' > > it just screams 'anemic domain model' at me. I would suggest the User object > > in this case validates its email address. It may well delegate the task to > > some utility method object's validateEmail() bt that should be up to the > > User to decide if it uses another object or does the job itself. > > > Another question - would you really care about validating an email address > > if its only a login and no data is actually being saved? > > > I'm no expert in this either but I tend to have the service objects handling > > exceptions. My lower level DAO's etc tend to return Void on insert, update > > and delete actions and if an exception is thrown the service objects deal > > with it (or let it go to the generic exception handler). ie if a > > non-critical logging action fails I just catch it at the service layer, send > > a Notification email/sms to support staff and the user continues using the > > app, unaware anything went wrong. If a save() fails then we have to take > > more drastic action and the user has to be aware of it. > > > For bean validation I have stolen an idea off Brian Kotek and use a Result > > object. This works well because as well as a simple isError() and > > getMessage() I can also store an array of structs for individual field > > errors so when the form is re-displayed I can show a generic message at the > > top of the page and each error field can be highlighted with individual > > messages. > > > Alan > > > ----- Original Message ---- > > From: Matthew <[EMAIL PROTECTED]> > > To: CFCDev <[email protected]> > > Sent: Tuesday, October 21, 2008 4:23:39 AM > > Subject: [CFCDEV] Re: Message managment in OO programming > > > Hi Barney > > > Thanks for the response again. I realised after I wrote that session > > question that the service layer shouldn't do it - thanks for > > clarifying. > > > Regarding your second point: I'm not sure I follow your explanation - > > what does "inflate" mean? Perhaps I'll try to re-ask the question. Q: > > When a user login form is submitted should the service layer validate > > the email address (perhaps delegating this task to a UDF object)? > > > Regarding the original Q: I'm starting to get it now. So the business > > objects just throw an exception and leave it for the UI layer to deal > > with it. That would mean if your app was using Mach-II you'd catch it > > at the listener level and perhaps do nothing, or log it, and/or > > redirect to a new event etc etc. Where as if your app was invoking > > this service layer via a web service layer (which is the UI) than the > > web service layer would need to trap the exceptions and handle them > > accordingly e.g. pass a coded error back to the web service invoker. > > > I'd be interested to see if others agree with this solution? > > > Cheers > > Matthew > > > On Oct 21, 11:38 am, "Barney Boisvert" <[EMAIL PROTECTED]> wrote: > >> The successful return of the emailUserPassword() service method would > >> indicate that it's been sent. If there were a problem sending it, an > >> exception would be raised. > > >> The service layer shouldn't know about the session scope, that's a UI > >> construct as it's bound to HTTP. Consider if your service layer > >> accepts both requests from an HTTP UI (accessed via browser) and a JMS > >> buss via an event gateway. No sessions with the latter, so your > >> service layer shouldn't depend on them. If you need to track user > >> state, that happens at the UI layer. > > >> For #2, I'd expect emailUserPassword() to either be passed a valid > >> user (in which case your scenario can't happen), or be passed an email > >> address to "inflate" via a call to some inflation method. In the > >> later case, that inflation method (wherever it lives) would > >> undoubtedly raise a InvalidEmailException or something if it can't > >> find the address which the emailUserPassword() method would ignore and > >> let bubble back up to the UI. So in either case, it's the controller > >> that has to deal appropriately with that exception, and the actual > >> notification method is unaware that it can even happen. I'd lead > >> towards the first approach, where the controller inflates the user > >> first, but that's personal preference. > > >> cheers, > >> barneyb > > >> On Mon, Oct 20, 2008 at 5:16 PM, Matthew <[EMAIL PROTECTED]> > >> wrote: > > >> > Exceptions are meant to be used when there is a problem, so what if > >> > you wanted to pass a message e.g. lets say someone has forgotten their > >> > password so that submit their email via the "Forgot my PW" form and > >> > when the service layer fires off the email with the pass (or perhaps > >> > passes the task to a notification object... but let's keep it simple > >> > for now), so how would you pass back to the view that the password has > >> > been sent? > >> > A few other questions: > >> > 1. Would you push/copy/inject the User bean into the session scope at > >> > the service layer? > >> > 2. Would you do the form validation at the service layer e.g. validate > >> > that they have typed in a valid email (this makes sense to me because > >> > why bother instantiating a BEAN/DOA if they haven't even entered a > >> > valid email)? > > >> > Cheers > >> > Matthew > > >> > On Oct 21, 10:26 am, "Barney Boisvert" <[EMAIL PROTECTED]> wrote: > >> >> For both of those cases, I'd use an exception. The UI layer can catch > >> >> the first one and reprompt for the username. The second one should > >> >> probably just bubble all the way up to the global onError handler, > >> >> since the app is dead without the DB, at least for processing logins. > >> >> By the time gets to the service layer, all your user validation should > >> >> be complete. As such, if an error comes up that the service layer > >> >> can't handle by itself (e.g. something besides a transaction > >> >> deadlock), it's fatal to the service layer and bubbles out. Maybe the > >> >> UI layer handles it (like invalid username exceptions), or maybe not > >> >> (like database is dead), but the service layer needn't care. > > >> >> cheers, > >> >> barneyb > > >> >> On Mon, Oct 20, 2008 at 4:23 PM, Matthew <[EMAIL PROTECTED]> > >> >> wrote: > > >> >> > Hi everyone > > >> >> > How are people managing messages in their OO code i.e. how do you > >> >> > pass > >> >> > errors or comments from a component which is deep down in the > >> >> > business > >> >> > layer - say perhaps from a DAO back up to the view. I've had a look > >> >> > at > >> >> > various projects which I've downloaded and seen that some people use > >> >> > CFTHROW type=application which means that this can be picked up at > >> >> > the > >> >> > top level (but it seems odd to me because it is making the assumption > >> >> > that some other object / code will pick it up i.e. it is not > >> >> > explicitly saying "I had an error"). Some other projects built arrays > >> >> > of messages and returned this. But how would you use such an array > >> >> > solution if you were wanting to pass a bean as well as the array (I > >> >> > guess you would have to return a structure with the array and bean > >> >> > inside)?. > > >> >> > Perhaps an example would help, so let's take a very common user-login > >> >> > scenario > > >> >> > 1. User enters email/password. > >> >> > 2. Controller/Listener passes form vars to service layer. > >> >> > 3. Service layer invokes BEAN and passes it to the DAO for > >> >> > population. > >> >> > ERROR TYPE 1: user not found (Q: So how would you pass this ERROR > >> >> > back > >> >> > to the view.). > >> >> > ERROR TYPE 2: DB error (Q: Perhaps there was a table error or DSN > >> >> > error or database was down. So how would you pass this ERROR back to > >> >> > the view. Obviously you would want to email the administrator with > >> >> > the > >> >> > specific error as well as provide a generic message to the user). > > >> >> > Cheers > >> >> > Matthew > > >> >> -- > >> >> Barney Boisvert > >> >> [EMAIL PROTECTED]://www.barneyb.com/ > > >> -- > >> Barney Boisvert > >> [EMAIL PROTECTED]://www.barneyb.com/ > > >http://mail.yahoo.com > > -- > Barney Boisvert > [EMAIL PROTECTED]://www.barneyb.com/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
