c# - 将 Identity 2.0 抽象到领域模型层

标签 c# asp.net-identity onion-architecture

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

我的核心中有一个 ApplicationUser

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

在我的数据访问层中,我使用的是 Entity Framework 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 和数据项目中的所有身份代码。

在我的其他项目中,我到处都添加了 Identity 和 EF,包括 Domain 项目。你猜怎么着?没有什么不好的事情发生。

我也查看了已经提供的解决方案 link访问 Imran Baloch 的博客。对我来说,为了获得客户值(value)而付出了很多努力。

再说一遍,如果不重写一堆代码(不喜欢),就没有什么好的方案可以把EF和Identity分开。因此,要么将 EF 添加到您的域项目(不喜欢它),要么将您的身份代码保留在 Web/数据项目中(有时不可能,所以我也不喜欢它)。

很抱歉,但这是 .Net 的低级限制。

关于c# - 将 Identity 2.0 抽象到领域模型层,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/25265291/

相关文章:

c# - 洋葱架构 : Should we allow data annotations in our domain entities?

c# - 单元测试会不必要地混淆代码,还是有更好的方法?

asp.net-core - 从 lambda 授权者响应中提取身份

c# - Asp.Net 身份从一个应用程序池身份生成密码重置 token 并在另一个上验证

mvvm - 领域模型对 View 模型的依赖有多糟糕?

c# - 使用洋葱架构使用多个 API 和 Web 服务

System.Type 的 C# 反序列化从加载的程序集中抛出类型

c# - C#中如何抓取TCP数据包

c# - 如何在 C# 文件中创建 List<T> 实例

azure - ASP.NET Core 2.2 - 密码重置在 Azure 上不起作用( token 无效)