Come see other top popular articles surfaced by Aspnet experts!…

Certainly makes our class structure more complex if we have a lot of this sort of thing, but as you say, it’s not exception based which removes the concerns re: performance.

I wish others had seen the talk at DevWeek – I’ve bounced ideas with one of the guys here who also saw it, and he’s convinced also that we’re delivering in the way Jeffrey Richter defined, but it’s really difficult to find any evidence – his slide decks seem to have vanished!

I shall go on a hunt and see if I can dig out any more, though I do like your approach Martin, thanks for commenting

How about creating a class called LoginResult, exposing the following public properties:

1. AuthenticatedUser of type User
2. Result of type loginResultEnum
3. Message of type string.

Set ProcessLogin to return an instance of LoginResult.

A successfull login will result in a LoginResult instance containing the user in the AuthenticatedUser prop and a Result value.
An unsuccessful login will result in a LoginResult instances withAuthenticatedUser set to null, but the Result value property will reflect the reason why the login failed and the Message property will contain any message to used by the view.

That way then, the controller checks the LoginResult.Result property then decides what to do from there.

Not an exception in site… but the controller still gets all the info it needs to pass to the view.

Exceptions aren’t necessarily evil but I’d argue that they’d only be raised to handle things like the DAL borking out in it’s call or other things that you haven’t any particular control over. Just an idea!

One other thing. Would it be possible to pass the username and password into a DAL method (say Dal.GetUser(string username, string password))? That way then, if a user is returned, you’ll know the username and pwd are valid.