Replies: 2 comments 1 reply
-
fwiw, I have absolutely no idea how to make it optional. The changes to support Blazor required using DI very deep within CSLA, because in Blazor the only way to get the current user identity is via DI. There literally is no other option. Because the CSLA rules engine includes authorization rules, and those extend into business classes, the data portal, and various UI helper types, all of those aspects of CSLA were forced to switch from static references for the current identity to a DI-based model where something is injected to get the current identity. As a result, nearly all the static methods across the entire framework became instance methods. At the very core of this is |
Beta Was this translation helpful? Give feedback.
-
It was a big and scary change to the framework that Rocky had to undertake and as I helped out on the fringes, I too felt concern at the impact on older codebases. However, I also understood that it was a necessary move. Now that we have DI in CSLA - an enormous undertaking that Rocky managed to deliver - we can more easily evolve the framework. Some of the changes I made for interceptors in CSLA 6 were much easier because of us having DI as a tool in the toolbox. There is no absolute need to upgrade older systems to CSLA 6. It's not a small change to do so, so the benefit has to outweigh the cost. However, as has been said elsewhere, it is achievable through a bit of graft, some change by rote. Some day soon I'll do it on DesiGen - but admittedly, probably not today. |
Beta Was this translation helpful? Give feedback.
-
Per my question post concerning the difficulties in upgrading to CSLA 6+ due to the requirement to use Dependency Injection, I would be interested to learn what the community thinks of this feature.
Thank you.
3 votes ·
Beta Was this translation helpful? Give feedback.
All reactions