Open SkyeHoefling opened 4 years ago
Well, that sounds like a plan to me. As for the ComponentFactory, I guess if it's public we need to mark it deprecated and remove it later 😁
We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically. If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!
We talked today about changing lifetimes for objects created via DI in DNN 10, so I think updating (and deprecating, IMO) the ComponentFactory API to be backed by DI should happen then.
Are there any items in the ComponentFactory
that are configured in the web.config or other configuration file? Should we create another issue for the provider framework or use this issue for that?
If I remember correctly, DNN has a few items that are similar to Dependency Injection. I think it makes sense to try and normalize all of these to use Dependency Injection
We have detected this issue has not had any activity during the last 90 days. That could mean this issue is no longer relevant and/or nobody has found the necessary time to address the issue. We are trying to keep the list of open issues limited to those issues that are relevant to the majority and to close the ones that have become 'stale' (inactive). If no further activity is detected within the next 14 days, the issue will be closed automatically. If new comments are are posted and/or a solution (pull request) is submitted for review that references this issue, the issue will not be closed. Closed issues can be reopened at any time in the future. Please remember those participating in this open source project are volunteers trying to help others and creating a better DNN Platform for all. Thank you for your continued involvement and contributions!
Description of problem
The
ComponentFactory
was originally implemented prior to Dependency Injection in the Dnn Platform. It uses a very similar technique of registering types for static instantiation. It should be migrated to Dependency InjectionDescription of solution
The solution I have in mind has 3 main components to it
ComponentFactory
implementation to use the Dependency Injection container to resolve all the types.ComponentFactory
usages at app startup to use Dependency Injection instead.ComponentFactory
as deprecated to ensure modules and vendors use Dependency Injection instead.Description of alternatives considered
Should DNN keep the API available for
ComponentFactory
?Since Dnn has taken a strong opinion on Dependency Injection, I think it should deprecate the
ComponentFactory
otherwise it just means there is another API that needs to be maintained that does the same thing as Dependency Injection.Screenshots
N/A
Additional context
The testing effort for this will be high
Affected browser
N/A