【问题标题】:Authenticated User and Service Layer认证用户和服务层
【发布时间】:2013-01-18 22:12:42
【问题描述】:

我有一个 MVC 4 应用程序,它使用不同类库中的服务层。

对该服务层的一些调用需要知道哪个用户在请求数据。

数据记录因用户角色而异。

为了防止耦合问题,我应该在请求中传递用户名 (HttpContext.User.Identity.Name) 还是应该使用相同的 HttpContext.User.Identity 在服务层直接访问它.名称。

我不确定是否应该从服务层隐藏 HttpContext。

【问题讨论】:

  • 用户的身份和访问权限应该由单独的服务管理。我只是将这样的 识别服务 作为需要与授权/身份验证机制交互的其他服务的依赖项传递。特别是因为您可能需要在所述服务中进行基于角色的授权检查。

标签: asp.net-mvc model-view-controller asp.net-mvc-4 separation-of-concerns service-layer


【解决方案1】:

将 HttpContext 传递给服务层可能看起来很诱人,但这是一个糟糕的选择。它将在 ASP.net 运行时服务和业务逻辑之间建立一个硬链接(这正是您要避免的,我假设)。最好的办法是创建代表登录用户的类,您可以将其填充到基本控制器中并将其传递给服务层。

这样,你可以两全其美

【讨论】:

    【解决方案2】:

    只需将当前经过身份验证的用户作为参数传递给您的服务层。永远不要在你的服务层使用HttpContext.User.Identity.Name

    例如:

    [Authorize]
    public ActionResult SomeAction()
    {
        string user = User.Identity.Name;
        this.someService.SomeOperation(user);
        ...
    }
    

    您的服务层不应该绑定到HttpContext

    【讨论】:

    • 服务层可以使用HttpRuntime、HttpContextBase、HttpRequestBase、HttpResponseBase吗?
    • 不,不应该。服务层不应有任何对 System.Web 的引用。
    • 我可以在服务层使用 System.Runtime.Caching 吗?
    • 所以,我只能在服务层使用共享程序集,而不能使用 System.Windows、System.Web 等特定技术。这是真的吗?
    猜你喜欢
    • 2018-02-14
    • 2011-01-02
    • 1970-01-01
    • 2013-02-23
    • 2012-03-27
    • 2019-05-29
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多