In a recent blog post I provided a bit of a status update to the community on the DNN Platform plans for a migration to .NET Core. In that post, I outlined a number of the key initiatives and the steps that were being taken to accomplish the goals. In this post, I can proudly proclaim that the DNN Community has delivered, and DNN 9.4.0 and later will have ASP.NET Core Dependency Injection support for all extension development types. This was made possible by a great contribution from Andrew Hoefling in collaboration with the entire Technology Advisory Group (TAG). In my opinion, this contribution is one of the biggest keystones to progressing forward.
An Excellent Example in Collaboration
Before I dive into the details of what this means, I wanted to take a moment to step back and highlight the amazing collaboration and communication that was exhibited in this pull request. With the community being a group of individuals volunteering all time given, myself included, efficient communication is key to help things move quickly. This contribution is a great example of how quickly things can be processed, even large contributions if they are documented well.
Andrew's initial issue was created to fix an issue within the DNN pipeline. The community was able to help him understand the history and help talk through some implementation details. Once the final pull request came in it included examples for usage, limitations and other information. For the reviewers, this made testing fantastic, but also makes it easier for us to include this in release notes. For this, I applaud Andrew and encourage us all to follow a similar standard of documentation as we continue to make large shifts in the platform.
Dependency Injection, So What?
Moving past the logistics of the change, your biggest question might be. Why do you care about Dependency Injection so much? Or, what the heck is dependency injection? If you are asking either of these or similar questions, you are not alone. For those that are non-developers, sadly, this change isn't something that can be easily witnessed or understood. However, I'll try to break this down a bit into some common themes that should be understandable by all.
Why Do We Care?
Dependency injection is incredibly important to the future of development within DNN for many reasons;
The DNN Platform has been in active development for more than 15 years. During this time, hundreds of developers have contributed to the source code, workarounds for old system limitations have been introduced, and many anti-patterns have introduced some code that is less than helpful. With all of this history, we often find sections of the site that are tightly coupled, or dependent upon each other. In some cases, we have Circular Dependencies, which are the absolute worst thing to deal with.
A benefit already included with Andrew's contribution is what appears to be a major performance improvement to the rendering of MVC modules by "fixing" one of the circular dependencies. For the developer types, this change removed a reflection call that was called (N) times per module, per page. For module heavy, MVC sites, the performance gains should be sizable.
Better Support For Unit Testing
By allowing dependencies to be injected, we open the world up for developers to better unit test their solutions. The current shift in software development places a strong emphasis on unit testing and code coverage, which, without support for Dependency Injection in DNN has been very hard to accomplish.
There is still a long way to go in this area; however, the first step was to be able to inject dependencies. The next step will be to update the DNN API's to get rid of static methods and to better support injection at the framework level. Work that will be continuing for a while.
Adherence to Current Standards
There was an existing pattern within DNN Platform, the Service Locator Pattern that allowed dependency injection to happen in the past. However, this was a limited implementation that did not properly follow industry best practices and introduced a learning curve for developers coming to the platform. With the adoption of the ASP.NET Core Dependency Injection library, all of the features will match the Microsoft documentation, lowering the adoption cost.
One could also argue that by supporting current standards we will be equipped to better acquire new talent to the community.
What is Dependency Injection
Thankfully, for the uninitiated Andrew has also taken it upon himself to properly document exactly what Dependency Injection is and how to use it in MVC, WebAPI/SPA, and WebForms modules. With these great posts, I'll defer to them for the proper answer to this question.
Recomendations to Developers
This new features opens the door to proper architecture with DNN Modules and solutions. I would strongly encourage developers to consider the adoption of these new practices as soon as they become available with 9.4.0. By properly using Dependency Injection, you can start to restructure legacy DNN Installations, which in the end will make the future transitions easier.
I also encourage everyone to test the 9.4.0 release heavily, there should be sizable performance improvements with these changes, however, continued real-world validation is imperative.
The future is bright, this is just one major success with many to follow.