2016-09-05 41 views
0

我有一个架构问题,我希望有人能够帮助我指导一个更理想的策略。我被迫做这种“代码味道”的方式。ASP.NET MVC 5,依赖注入问题中的自定义角色体系结构

我有两种不同的“角色”。我有内置的Identity Roles,并且有一组自定义的角色(用户组角色)。我将这些用户组角色存储在数据库中,实质上是用户标识,用户组角色标识和用户组标识之间的关系。我正在使用Ninject进行依赖注入UserGroupService,它处理将具有特定用户组角色的用户分配给用户组的所有CRUD操作。

我的第一个攻击计划是创建一个自定义授权属性,我可以将其放置在与Identity [Authorize(Role =“”)]属性类似的操作上。我没有任何运气,因为我不能注入一个服务到一个属性类(需要一个无参数的构造函数)。

之后没有奏效,我的第二个攻击计划是为IPrincipal写一个扩展方法,实质上是用User.IsInUserGroupRole(“”)来模拟User.IsInRole(“”)。这不起作用,因为我无法将服务注入静态类。

目前我被困在包含一些布尔模型的基于角色的逻辑涉及的每个视图的模型中。因此,例如:

public ActionResult Navigation() 
    { 
     var isSystemAdmin = User.IsInRole("Administrator"); 
     var isUserGroupAdmin = _userGroupService.IsUserGroupAdmin(User.Identity.GetUserId()) && !isSystemAdmin; 
     var isGeneralUser = !isSystemAdmin && !isUserGroupAdmin; 

     var model = new NavigationViewModel 
     { 
      IsSystemAdmin = isSystemAdmin, 
      IsUserGroupAdmin = isUserGroupAdmin, 
      IsGeneralUser = isGeneralUser 
     }; 

     return PartialView("_Navigation", model); 
    } 

这里的问题是,我该做的任何时候,我要确定用户是什么样的角色,目前在它的工作原理,但它的气味。

我失去了一些东西在这里?我认为最理想的选择将是能够称之为用户的扩展方法策略,但似乎无法做到这一点。

回答

0

构造函数DI不是访问依赖项的唯一方法。

每个IOC都有一种解决依赖的方法,您只需要对IOC容器进行引用。因此,即使您的属性需要无参数构造函数,仍然可以手动解析依赖项。

像这样的东西应该有所帮助:

http://www.c-sharpcorner.com/UploadFile/47fc0a/resolving-dependency-using-ninject/

的是它使用国际奥委会这样一个伟大的方式?可能不会,但它肯定会打败你现在正在做的事情。