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

Question

I am writing some asp.net custom server controls and looking for the best practice as to how to inject a dependency that the control needs.

When deciding on how to do this, there are a couple of factors which I am taking into consideration:

1) How easy would it be to inject this dependency through markup.
2) How easy would it be to inject this dependency through code-behind.
3) This injection has to be as early as possible in the control life cycle, preferably the control should have all of its dependencies available in the OnInit().

Bases on these factors, the only way I can think of doing this it so have a string property on the control which will have the fully qualities type to the dependency. Once the control initializes it can load that type and do what it needs to do.

Example :

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);
          }
     }
}

I run into this kind of situation all the time and was wondering if anyone else figured out another/better/different to inject the dependency.
Thanks :)

Answer 1

What I've done is on init of the control, query the DI container and populate those references. You could nest this logic in a specialized base class that your custom server control can inherit from, so then it's reused. OR: There is a special AddedControl method that is called everytime a control is added to the control tree. The caveat here is that it probably only calls the method on the parent control, and does not propogate up. It may work depending on your scenario.

There isn't much in the lifecycle that lets you know when a control is created (other than the AddedControl method or the Init method that runs at the beginning of the process) to be able to tap into, and you can't customize the constructor of the control.

In regards to #1, to use the markup approach would require tapping into the design-time aspect of controls, and leveraging the design time attributes to the fullest. But #1 means defining the mappings in markup, which is not quite the point of a DI container. The designer still needs the property or something to assign the reference to, so it would essentially be double work of defining the property, then defining something in the designer, when the DI container takes care of that for you.