我在may .net核心web应用程序中有多个图层。所以这两个是;
- 应用程序。WebApi
- 应用程序。服务
业务需要检查用户的角色或名称声明。所以我认为我可以通过App.Services层的依赖注入来使用IHttpcontextAccessor接口。我正在使用扩展方法来获取用户声明，如下所示。
public static class ClaimsPrincipalExtensions
{
public static string GetUserEmail(this ClaimsPrincipal principal)
{
return principal.FindFirstValue(ClaimTypes.Email);
}
public static string GetUserId(this ClaimsPrincipal principal)
{
return principal.FindFirstValue(ClaimTypes.NameIdentifier);
}
}
服务层实现如下
public class ProductService: IProductService {
IHttpcontextAccessor context;
public ProductService(IHttpcontextAccessor context){
context = context;
}
....
....
public IEnumerable<Product> Get(){
var userRoles = context.HttpContext.User.GetUserEmail();
....
}
}
所以我在业务层使用IHttpcontextAccessor。但它是web api的一部分。这是否适合专业的解决方案?或者还有别的办法吗?
根据我的经验，在ASP中。. NET开发人员倾向于不太担心这些隔离问题(也不担心例如贫血域)。
在大多数系统中，特别是较小的系统中，业务逻辑和API之间存在大量耦合;例如，通过使用过滤器和中间件。
所以，从这个意义上说，它可以被看作是"合适的"，只要它不妨碍你实现重要的项目需求，例如能够独立于API运行应用程序核心。
但是如果你想以一种体面和现代的方式构建你的解决方案，避免这样做是有意义的。
直截了当的解决办法
一个直接的解决方案是将给定的数据提取到一个单独的"服务"中，并在消费给定服务的层中定义接口。然后在WebApi项目中实现接口。
一个很好的例子是Jason Taylor的Clean Architecture Template，其中你有一个在应用层定义的ICurrentUserService接口，具体的实现驻留在web层。
它还使用IHttpContextAccessor来提取有关登录用户的信息，因此它似乎是您想要做的一个很好的示例。
帮助引用
我知道在这里链接YouTube视频是不习惯的，但似乎你的主要专业领域不是ASP。所以我推荐Jimmy Bogard的Vertical Slice Architecture讲座，以及Jason Taylor的Clean Architecture讲座。它们描述了一种相当现代的使用ASP的方式。NET Core可以减轻开发人员在以后的项目中遇到的许多结构性问题。当然，这也不是什么灵丹妙药;对于简单的CRUD应用程序，这些开销可能不值得。
如果你有其他的顾虑或问题，请告诉我，这样我可以使这个答案更有用。