views:

400

answers:

3

Is it OK - best practise wise - to use the second layer to redirect the user?

For example:

public static void ForceLogin()
{
    HttpCookie cookie = HttpContext.Current.Request.Cookies[cookieName];

    if (cookie != null)
    {
        if (Regex.IsMatch(cookie.Value, "^[0-9]+\\.[a-f0-9]+$"))
        {
            using (EibxDataContext db = new EibxDataContext())
            {
                int count = db.Logins.Count(l => l.Password == cookie.Value);

                if (count == 1)
                {
                    return;
                }
            }
        }
    }

    HttpContext.Current.Response.Redirect("~/Login.aspx");
}

At the last line, I use the Business/Service Logic Layer to redirect the user to the login page.

Should this be done in the Presentation layer?

A: 

I would say that you're correct to do it in the business logic. Presentation layer shouldn't be making decisions about routing.

duffymo
Maybe not "presentation", but redirection/routing is still a "user interface" issue, not necessarily the job of your service code. Why should that know about the web-server at all?
Marc Gravell
Agreed with Marc. Not downvoting (obviously the OP liked this answer), but I'd never want any tier other than presentation handling redirects. It's an entirely UI concept. Have the business layer return that the login wasn't successful, and let the UI figure out what to do.
John Rudy
The web controller is part of the view in that case. You're thinking about something that I'd call the service layer. The controller that accepts requests, routes to services, and redirects to the appropriate view is written and deployed with the client.
duffymo
I agree completely that services should neither know nor care how their responses are consumed. But that's exactly why the controller needs to be part of the client tier.
duffymo
Which is not what the OP mentioned. The OP mentioned specifically the business/service logic layer -- which in traditional architecture is very specifically *not* UI-aware at all. If this app needs to be extended to support web services, rich clients or any other different presentation, OP's hosed.
John Rudy
(Note: My last comment was apparently being typed while @duffymo.myopenid.com was typing his last. Please read as though mine was a response to @duffy's first comment, not second.)
John Rudy
I agree with John Rudy's "hosed" comment. I was thinking in terms of separate web services and client. In that case, it sounds like we agree.
duffymo
+3  A: 

It depends on how you define your layers; for example, my "business logic" is usually logic related to the problem I am trying to solve, and knows nothing of the UI. So it can't do a redirect, as it has no access to the request/response.

Personally, I'd do this at the UI layer; dealing with the raw interactions such as being gate-keeper and custodian is part of the UI layer's job for a web app. IMO. For example, via an http-module, which is (by definition) a UI-level component.

Marc Gravell
+6  A: 

Absolutely not. The business logic layer should make the decision, the UI layer should do the redirect. The business layer shouldn't know anything about HttpContext nor should it be directly reading cookies. Pass the relevant information into the business layer so that the business layer can make the decision, and pass the decision out to the UI layer so that it can work on the resultant decision.

Here's the reason... what if the business layer is used from a web service? How can the business layer do a redirect in that instance? Or suppose it's used with a non-web client? Redirection has no meaning in that context. If you change your UI layer, that should not affect your business logic layer, and mixing in redirects and cookie reading into the business layer will necessitate that with the proposed design.

Robert C. Barth
Thank you for the answers. I preferred this answer because of the last section, which cleared things up for me. Thank you.
Eibx