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

时间:2018-01-05 17:49:01

标签: c# asp.net-core-2.0

我们已将业务逻辑分离为所有其他项目引用的单一类库。我们的前端是Web Forms,之前有一个单例,可以很容易地访问当前的Web上下文(2)。在ASP.NET Core 2.0中,这已经消失,似乎被依赖注入取代。

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

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

HttpContext.Current

这很有效,因为处理Creator的代码完全由基类处理,而对派生类是不可见的。派生类正常工作。但是在ASP.NET Core 2.0中,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); } 单例已经消失。显然被DI取代。所以我不能再像以前那样检查当前登录的用户。我环顾四周,但似乎无法找到访问当前网络环境的方法。所以我现在认为复制我的功能会像这样:

HttpContext.Current

这有效,但有一些不良特征。

  • 我现在必须为所有70个表实体中的新构造函数传递另一个参数(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"); } } )。这是很多添加的代码,我们甚至没有谈到我必须获取并在每个呼叫站点传递参数的事实。
  • 我需要使用DI将当前用户注入任何计划可能创建新对象的页面模型或控制器。
  • 根据指南我读到的模型绑定将从帖子的参数初始化我的表实体的新实例。这不会使用无参数构造函数,因此在Creator中留下空引用吗?我的业务逻辑如何在这里应用?我是否需要自己从POST主体构建我的实体以在构造函数中使用逻辑?

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

1 个答案:

答案 0 :(得分:1)

  

我忽略了什么吗?

最有可能是抽象并完全接受DI。

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

  

我现在必须为所有70个表实体中的新构造函数传递另一个参数(用户创建者)。这是很多添加的代码,我们甚至没有谈到我必须获取并在每个呼叫站点传递参数的事实。

或者您可以使用DI。让DI框架了解所需的参数并询问您的表格。它应该创建对象并传递所有必要的参数。

  

我需要使用DI将当前用户注入任何计划可能创建新对象的页面模型或控制器。

见上文。

  

根据指南我读到模型绑定将从帖子的参数初始化我的表实体的新实例。这不会使用无参数构造函数,因此在Creator中留下空引用吗?我的业务逻辑如何在这里应用?我是否需要自己从POST主体构建我的实体以在构造函数中使用逻辑?

见上文。

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