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] http://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 -~----------~----~----~----~------~----~------~--~---
