我有一个webapi,其中在startup.cs文件中使用app.CreatePerOwinContext,但我想将该webapi迁移到.net core 2.1。因此,由于无法对CreatePerOwinContext进行任何替代,我一直停留在这一点上。
这是我的webapi代码:
public static UserManager<IdentityUser> Create(IdentityFactoryOptions<UserManager<IdentityUser>> options, IOwinContext context)
{
var manager = new UserManager<IdentityUser>(new UserStore());
return manager;
}
public void ConfigureAuth(IAppBuilder app)
{
app.CreatePerOwinContext<UserManager<IdentityUser>>(Create);
...
}
那么如何在.net core 2.1中转换以上代码?
答案 0 :(得分:1)
该方法用作service locator来加载依赖项,然后在整个代码中访问它们。服务位置本身是is considered an anti-pattern,不建议在大多数现实世界中使用。
相反,人们现在使用IOC containers来管理其依赖项注入。在ASP.NET MVC Core中,现在提供了一个轻量级的“足够好”的IOC容器作为框架的一部分。
Microsoft提供了an overview in this article,但简短的版本是在Startup.cs中,将依赖项树注册在ConfigureServices下(通常使用扩展方法,因此Startup.cs不会太大)。
注册依赖项后,可以通过属性注入,构造函数注入或方法参数注入来加载它们。这样可以产生比标准服务位置更易于维护的代码。
编辑:
如果您真的因为技术问题可以接受或者因为业务案例需要当前的设计而真正坚持管理服务定位器,那么我建议您将工作从OwinContext过渡到HttpContext。
在ASP.NET Core中,您可以通过将HttpContextAccessor注入到类中并更改OwinContext调用以从HttpContext的键值存储中提取来访问HttpContext。
可以在in this SO answer中找到有关注入HttpContextAccessor的说明。只需使用HttpContext.Current.Application["myObject"]
存储KVP。
我不建议这样做,但我愿意分享,因为我了解截止日期的现实与建筑的理想主义。