c# - 从 ASP.NET Core 2.0 中的类库访问当前上下文的推荐方法？

Question

我们已将业务逻辑分离到一个所有其他项目都引用的单一类库中。我们的前端是 Web 窗体，之前有一个单例，可以非常轻松地访问当前的 Web 上下文 (HttpContext.Current)。在 ASP.NET Core 2.0 中，这已经消失，似乎被依赖注入(inject)所取代。

对我来说，DI 似乎是朝着正确方向迈出的一步，我绝对可以看到其中的好处。但是对于我的类库，我看不到使用 DI 的方法。因此，要访问满足我的业务需求所需的所有信息，我必须将所有这些信息作为参数传递。

例如，我每次创建新的数据库条目时都会记录当前用户。使用我的网络表单应用程序(我正在更换它)，我的业务逻辑库可以像这样获取用户:

public abstract class TableBase
{
    public User Creator { get; private set; }

    internal TableBase() {}//EF select constructor

    internal TableBase(bool newRow)
    {
        Creator = User.Current;
    }
}

public class Client : TableBase
{
    public string Name { get; set; }

    protected Client() {}//EF select Constructor

    public Client(string name) : base(true)
    {
        Name = name;
    }
}

public class User
{
    public static User Current => GetUserFromContext(HttpContext.Current);
}

这非常有效，因为处理 Creator 的代码完全由基类处理并且对派生类不可见。派生类只是工作。但是在 ASP.NET Core 2.0 中，HttpContext.Current 单例已不存在。显然被 DI 取代了。所以我不能再像以前那样检查当前登录的用户了。我环顾四周，但似乎找不到访问当前网络上下文的方法。所以我目前认为复制我的功能会像这样工作:

public abstract class TableBase
{
    public User Creator { get; private set; }

    internal TableBase() {}//EF select constructor

    internal TableBase(User creator)
    {
        Creator = creator;
    }
}

public class Client : TableBase
{
    public string Name { get; set; }

    protected Client() {}//EF select constructor

    public Client(string name, User creator) : base(creator)
    {
        Name = name;
    }
}

public class MyPage : PageModel
{
    private readonly User _currentUser;
    private readonly DbContext _context;

    public MyPage(User currentUser, DbContext context)
    {
        _currentUser = currentUser;
        _context = context;
    }

    public async Task<IActionResult> OnPostAsync(string name)
    {
        var newClient = new Client(name, _currentUser);
        _context.Clients.Add(newClient);
        await _context.SaveChangesAsync();
        return RedirectToPage("/Index");
    }
}

这可行，但有一些不良特征。

• 我现在必须为所有 70 个表实体中的新构造函数传入另一个参数(User creator)。这是很多添加的代码，我们甚至还没有谈到我必须在每个调用站点获取和传递参数这一事实。
• 我需要使用 DI 将当前用户注入(inject)任何计划可能创建新对象的页面模型或 Controller 。
• 根据我阅读的指南，模型绑定(bind)将根据帖子的参数在帖子上初始化我的表实体的新实例。这不会使用无参数构造函数并因此在 Creator 中留下空引用吗？如何在这里应用我的业务逻辑？我是否需要自己从 POST 主体构建我的实体以利用构造函数中的逻辑？

也许这是一个必要的邪恶。它还消除了对我的业务逻辑库以前包含的 System.Web 的依赖，使其更具可移植性。但是当我希望 DI 减少我编写的代码量时，似乎还有很多工作要添加。我的期望不正确吗？我是否忽略了什么？

Answer 1

Have I overlooked something?

最有可能的抽象和完全拥抱 DI。

(我几乎只使用 Autofac for DI ，包括使用它而不是 Core 的实现，我与该项目没有任何关系)。

I now have to pass in another parameter (User creator) for the new constructor in all 70 of table entities. This is a lot of added code and we haven't even talked about the fact I have to acquire and pass the parameter at each call site.

或者您可以使用 DI。让 DI Framework 知道所需的参数，并为您的表询问它。它应该创建对象并传递所有必要的参数。

I need to use DI to inject the current user into any page model or controller that plans on possibly creating a new object.

见上文。

According to the guides I read model binding will initialize a new instance of my table entities on post from the parameters of the post. Wouldn't this use the parameterless constructor and thus leave a null reference in Creator? How can my business logic be applied here? Do I need to build my entity myself from the POST body to utilize logic in the constructor?

见上文。

恕我直言，DI 的全部要点是说这里是我需要的东西，这里是那些东西需要的所有东西现在给我我的对象。 DI 应该处理其他所有事情。