[Enhancement]: Best practice for constructor injection how-to (markdown page in repo)

[paul-hammant]

Is there an existing issue for this?

• I have searched the existing issues

Description of problem

Teams building a WebForms-pattern module (.ascx/code-behind) on DNN Platform 10.x, targeting .NET Framework 4.8, and want to use real constructor injection rather than a static service-locator pattern for module dependencies. Since .NET Framework 4.7.2, System.Web.HttpRuntime.WebObjectActivator allows true constructor injection into Page/UserControl/MasterPage. Before teams adopt it, they wouldwant to check DNN's official guidance and current status directly.

1. I have came across an earlier note (around Added Dependency Injection to all Module Patterns and Removed Circular Dependencies in Module Pipeline #2774 / Dependency Injection in WebForms #4098 and the DotNetNuke.ModulePipeline/ModuleControlPipeline work) that an initial attempt at using WebObjectActivator caused crashes, possibly related to ClientDependency. Has that been root-caused and resolved? Is WebObjectActivator-based construction considered safe for DNN module activation today?
2. The current DI docs cover MVC, Razor3, and SPA/Web API modules — is there an equivalent, officially recommended pattern for getting constructor injection specifically into a classic WebForms module's UserControl code-behind via WebObjectActivator, or is property/setter injection still the supported approach for that module pattern?
3. Does ModuleControlPipeline/IModuleControlPipeline interact with WebObjectActivator in a way teams should account for, or are they unrelated mechanisms that happen to both be part of the DI story?
4. For reference, the shape of wiring I have evaluated is the same as Microsoft's own (now-retired, reference-only) AspNetWebFormsDependencyInjection sample - setting HttpRuntime.WebObjectActivator from Application_Start via a small IServiceProvider adapter over the container. Is that general
   approach (regardless of container) known to be compatible with DNN's module activation, or is there a DNN-specific gotcha we should know about first?
5. Last reference - I co-created PicoContainer for Java before Depencency Injection was called that. Later, Unity container methods looked a lot like PicoContainer;s ones.

TL;DR: Current D.I best-practice codified in a how-to page would be fantastic :) :)

Sources

• DNN Platform Releases
• PR #2774 - Added Dependency Injection to all Module Patterns and Removed Circular Dependencies in Module
  Pipeline
• PR #4098 - Dependency Injection in WebForms
• DNN Docs --Dependency Injection: WebForms
  Modules
• Discussion #5625 - Microsoft .NET to .NET Core Upgrade Assistant
• DNN, .NET Core, and the Road Ahead - Mitchel Sellers

Description of solution

Markdown page talking about pattern and linking to tight example code (or project)

Description of alternatives considered

Briefly considered ServiceLocator and Singleton (dssign patterns) but the last 26 years of my career have been spent arguing against those!

Anything else?

No response

Do you plan to contribute code for this enhancement?

• Yes

Would you be interested in sponsoring this enhancement?

• Yes

Code of Conduct

• I agree to follow this project's Code of Conduct

[valadas]

I have not done much webforms recently but I am pretty sure that constructor injection was fixed to work in webforms whether as a DNN module control or normal webforms control loaded manually. Maybe @bdukes can confirm here...

[jeremy-farrance]

I really love the idea of including how-to Markdown docs like this right in the project. Especially since there is not an easy to find modern reference for this in the docs or online. There are a lot of modern coding patterns where we want to do things the right/better way, but finding an example is just impossible.

Also, I could be mistaken, but I think work similar to this (constructor injection) was done on the DDR Menu module last year. So that also might be a reference for some of this... if its up to the modern standard or best practices.