.Net在nTier App中的会员资格

Question

假设我有一个ASP.Net MVC应用程序,这个应用程序(UI)引用业务逻辑层(BLL),BLL引用我的数据访问层(DAL).

我正在使用自定义成员资格和角色提供程序进行授权.

我正在尝试确定哪些层需要引用我的成员资格提供程序.

在MVC中,您可以通过以下方式执行授权检查:

[Authorize(Roles = "SomeRoleName")]
public ActionResult Index()
{
//do something
}

在我的BLL中,我可能想检查用户是否也在角色中:

public static bool IsRoleEditor(User user, Role userRole)
  {
   bool retValue = false;

   if (user.Application.AppID == UserRole.Application.AppID)
   {
        if (Roles.IsUserInRole("ModifyRoles"))
        {
           retValue = true;
        }


    return retValue;
   }

如果我这样做,我将不得不在两个层中引用和实例化Membership类.这是构建这样的应用程序的正确方法吗？似乎有很多冗余.

由于我有一个BLL,我是否避免使用"[Authorize(Roles ="SomeRoleName")]"属性,而是从MVC代码中调用BLL函数来检查用户是否在角色中？如果我这样做,MVC仍然需要引用成员资格提供程序进行身份验证,无论如何要利用Login和其他ASP控件,对吗？

我离开基地并向错误的方向前进吗？

Answer 1

在我看来，这是成员/角色设计的弱点。

我解决这个问题的方法，例如在分布式 n 层应用程序中的 UI 层和 BLL 层上进行基于角色的授权，将在 BLL 层中公开一个服务，该服务公开相关位（GetRolesForUser 等）并通过调用服务端的RoleProvider来实现。

然后在客户端实现一个自定义的RoleProvider，该RoleProvider是通过调用BLL暴露的服务来实现的。

这样UI层和BLL层就共享同一个RoleProvider。UI层可以使用当前用户角色的知识来改进UI（例如，隐藏/禁用与未授权功能相对应的UI控件），并且BLL可以确保用户不能执行他们未经授权的业务逻辑。