ASP.NET 自定义服务器控件中的依赖项注入

本文关键字：依赖 注入 NET 自定义 服务器控件 ASP | 更新日期: 2023-09-27 18:32:06

我正在编写一些 asp.net 自定义服务器控件，并寻找有关如何注入控件所需的依赖项的最佳实践。

在决定如何做到这一点时，我考虑了几个因素：

1） 通过标记注入这种依赖关系有多容易.
2）通过代码隐藏注入此依赖项有多容易.
3） 此注入必须在控件生命周期中尽可能早地进行，最好控件应该在 OnInit（） 中提供其所有依赖项。

基于这些因素，我能想到的唯一方法是在控件上有一个字符串属性，该属性将具有依赖项的完整质量类型。一旦控件初始化，它就可以加载该类型并执行它需要执行的操作。

示例：

public class MyControl : CompositeControl
{     
     public string RepositoryType { get; set; }     
     protected IRepository Repository { get; set; }
     protected override void OnInit()
     {
          EnsureChildControls();
     }
     protected override void CreateChildControls()
     {
          if (!ChildControlsCreated)
          {
              Repository = ComponentFactory.Instanciate(RepositoryType);
          }
     }
}

我一直遇到这种情况，想知道是否有其他人想出了另一个/更好/不同的方法来注入依赖关系。谢谢:)

ASP.NET 自定义服务器控件中的依赖项注入

我所做的是在控件的初始化上，查询 DI 容器并填充这些引用。 您可以将此逻辑嵌套在自定义服务器控件可以从中继承的专用基类中，以便重复使用它。 或者：有一个特殊的 AddControl 方法，每次将控件添加到控件树时都会调用该方法。 此处需要注意的是，它可能只调用父控件上的方法，而不会向上传播。 它可能会起作用，具体取决于你的方案。

生命周期中没有太多内容可以让你知道何时创建控件（除了 AddControl 方法或在流程开始时运行的 Init 方法）可以利用，并且您无法自定义控件的构造函数。

关于 #1，使用标记方法需要利用控件的设计时方面，并充分利用设计时属性。 但是 #1 意味着在标记中定义映射，这不是 DI 容器的重点。 设计器仍然需要属性或要分配引用的内容，因此当 DI 容器为您处理时，定义属性，然后在设计器中定义某些内容，这本质上是双重工作。

相关文章：