将Identity 2.0抽象到域模型层



我正试图在我的ASP中实现Identity 2.0。. NET MVC 5解决方案,遵循洋葱架构。

我有一个ApplicationUser在我的核心。

namespace Core.DomainModel
{
    public class ApplicationUser {...}
}

在我的数据访问层中,我使用实体框架6.1,我的上下文来自IdentityDbContext,这里存在问题。ApplicationUser需由Microsoft.AspNet.Identity.EntityFramework.IdentityUser导出

namespace Infrastructure.DAL
{
    public class TestContext : IdentityDbContext<ApplicationUser> {...}
}

我的领域模型不应该引用Microsoft.AspNet.Identity.EntityFramework,这会违背洋葱的想法。

什么是好的解决方案?

是的,这是身份框架的大问题,我还没有找到好的解决方案。

我考虑将EF添加到我的域项目中,但在一个项目中决定反对它:域模型不知道ApplicationUser,只使用Id用于他们从

获得的当前用户
ClaimsPrincipal.Current.Claims
    .FirstOrDefault(c => c.Type == ClaimTypes.NameIdentifier)
    .Value

在那个项目中,我保留了Web和Data项目中的所有标识码。

在我的其他项目中,我已经添加了Identity和EF的所有地方,包括Domain项目。你猜怎么着?没发生什么坏事。

我也看到了解决方案,比如已经提供了Imran Baloch博客的链接。在我看来,做了很多工作,却没有获得任何客户价值。

只是重复一下我自己,没有好的解决方案可以在不重写一堆代码的情况下将EF与Identity分开(我不喜欢这样)。因此,要么将EF添加到您的Domain项目中(不喜欢它),要么将您的身份码保留在Web/Data项目中(有时不可能,所以我也不喜欢它)。

很抱歉,这是。net的底层限制。

您可以从Core名称空间继承IUser,用户管理器将会很高兴。您将需要用您自己的实现替换IUserStore。然后像这样初始化用户管理器:

new UserManager<ApplicationUser>(new YourNameSpace.UserStore<YourApplicationUser>()))

问题是您正在尝试使用Onion模式。在它的基础上,你将总是构建依赖关系。

为您正在创建的模型的单一责任而茁壮成长。你可以很容易地做到这一点,通过在每层实现单独的模型来遵循领域驱动设计:

  • BusinessLogic.Models。ApplicationUser
  • Presentiation.Models。ApplicationUser
  • DAL.Models。ApplicationUser

请注意,所有这些模型都是不同的类,即使它们具有100%相同的属性(尽管它永远不会是100%)。缺点是您可能需要从一个模型映射到另一个模型,但是如果您真正的目标是干净、模块化和可扩展的体系结构—这就是方法。提示您可以使用Automapper(或ExpressMapper)来避免映射所需的代码。

相关内容

  • 没有找到相关文章

最新更新