C# 三层Web应用程序

使用第二层重定向用户是否可以（最佳实践）

例如：

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");
}

在最后一行，我使用业务/服务逻辑层将用户重定向到登录页面

---

这应该在表示层中完成吗？

我认为您在业务逻辑中这样做是正确的。表示层不应该决定路由。

这取决于您如何定义层；例如，我的“业务逻辑”通常是与我试图解决的问题相关的逻辑，对UI一无所知。因此，它无法重定向，因为它无法访问请求/响应

---

就我个人而言，我会在UI层这样做；处理原始的交互，比如把关人和保管人，是web应用程序UI层工作的一部分。例如，通过http模块，它（根据定义）是UI级组件。

绝对不是。业务逻辑层应该做决定，UI层应该做重定向。业务层不应该知道任何关于HttpContext的信息，也不应该直接读取Cookie。将相关信息传递到业务层，以便业务层能够做出决策，并将决策传递到UI层，以便UI层能够处理结果决策

---

原因如下。。。如果业务层是从web服务使用的呢？业务层如何在该实例中进行重定向？或者假设它与非web客户端一起使用？重定向在该上下文中没有任何意义。如果您更改UI层，这不应影响您的业务逻辑层，而将重定向和cookie读取混合到业务层中将使拟议的设计成为必要。

可能不是“表示”，但重定向/路由仍然是一个“用户界面”问题，不一定是服务代码的工作。为什么要知道网络服务器呢？同意Marc的观点。没有向下投票（显然OP喜欢这个答案），但除了演示处理重定向之外，我再也不想要其他层了。这完全是一个UI概念。让业务层返回登录不成功的消息，并让UI知道该怎么做。在这种情况下，web控制器是视图的一部分。你在考虑我称之为服务层的东西。接受请求、路由到服务和重定向到适当视图的控制器是与客户端一起编写和部署的。我完全同意服务不应该知道也不应该关心它们的响应是如何使用的。但这正是为什么控制器需要成为客户端层的一部分，而OP并没有提到这一点。OP特别提到了业务/服务逻辑层——在传统体系结构中，这一层完全没有UI意识。如果此应用程序需要扩展以支持web服务、富客户端或任何其他不同的演示文稿，请访问OP的hosed。谢谢您的回答。我更喜欢这个答案，因为最后一节为我澄清了问题。非常感谢。