C# 在应用程序的服务层中使用AspNetCore Http dll好吗

给你一些背景：

我已经创建了一个多租户web应用程序

这里，对于任何请求，执行以下步骤

1. Fetch the user information such as ID from HttpContext object
2. Then getting the approprate db name from a common db.
3. Updating the dbContext with the db name
4. And all my repository classes are instantiated based on this updated dbContext 

前两个步骤是在类库项目（服务层）中完成的，为了获得用户ID，我必须访问HttpContext对象，AspNetCore.Http.dll正被手动引用（获取dll并复制到文件夹中并添加到项目中）

---

正确的方法是什么？在类库项目中使用NetCore库是一个更好的主意吗？

现在还不完全清楚您在这里做什么，但是对于

HttpContext

，有几点应该可以帮助您：

仅仅有参考资料是不够的。您必须手动删除DLL这一事实只会增加这样的可能性，即这无论如何都不会起作用

HttpContext

仅存在于请求管道的上下文中。不管您是否可以获得一些代码进行编译，如果它没有在该管道中运行，

HttpContext

将为null，对您来说毫无用处

无论如何，库类通常不应该依赖于

HttpContext

。如果在库类中需要类似于用户id的内容，则应将该用户id本身传递到构造函数或方法中（取决于最有意义的方法）。如何从

HttpContext

获取用户id的逻辑是您的类可能不应该拥有的领域知识

如果要直接使用

HttpContext

，则应插入

IHttpContextAccessor

。这将要求您使用

services.AddHttpContextAccessor（）

在ASP.NET核心应用程序中添加服务。完成后，就可以通过该访问器实例访问当前请求的

HttpContext

。但是，如果您在请求管道之外，它仍然是空的

---

现在还不完全清楚您在这里做什么，但对于

HttpContext

，有几点应该可以帮助您：

仅仅有参考资料是不够的。您必须手动删除DLL这一事实只会增加这样的可能性，即这无论如何都不会起作用

HttpContext

仅存在于请求管道的上下文中。不管您是否可以获得一些代码进行编译，如果它没有在该管道中运行，

HttpContext

将为null，对您来说毫无用处

无论如何，库类通常不应该依赖于

HttpContext

。如果在库类中需要类似于用户id的内容，则应将该用户id本身传递到构造函数或方法中（取决于最有意义的方法）。如何从

HttpContext

获取用户id的逻辑是您的类可能不应该拥有的领域知识

如果要直接使用

HttpContext

，则应插入

IHttpContextAccessor

。这将要求您使用

services.AddHttpContextAccessor（）

在ASP.NET核心应用程序中添加服务。完成后，就可以通过该访问器实例访问当前请求的

HttpContext

。但是，如果您在请求管道之外，它仍然是空的

---

我通常会将从请求中获得的任何信息（如

UesrID

）从我的控制器传递到服务层方法。如果需要将其他数据与UserID一起传递，该怎么办？假设我需要从请求的头传递一些其他ID。然后，我所有的服务方法都应该更新。这没关系。你所说的实际上是一个坏习惯。您实际上是在隐藏依赖项。您的类需要一个用户id和一些头。与实际制作API的这一部分不同，您只是尝试传入一些类甚至不应该知道的对象，只是碰巧包含了这些信息（以及许多其他它不需要的东西）。如果现在只是id，但以后您还需要一个标头，这实际上是对API的一个突破性更改，应该这样处理。我通常会将从请求中获得的任何信息（如

UesrID

）从我的控制器传递到服务层方法。如果您需要将其他数据与UserID一起传递，该怎么办？假设我需要从请求的头传递一些其他ID。然后，我所有的服务方法都应该更新。这没关系。你所说的实际上是一个坏习惯。您实际上是在隐藏依赖项。您的类需要一个用户id和一些头。与实际制作API的这一部分不同，您只是尝试传入一些类甚至不应该知道的对象，只是碰巧包含了这些信息（以及许多其他它不需要的东西）。如果它现在只是id，但以后还需要一个标头，那么这实际上是对API的一个突破性更改，应该这样处理。