@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/ __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.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 -~----------~----~----~----~------~----~------~--~---
