Move static properties of ApplicationContext to instance properties of Options objects

[TheCakeMonster]

We have a number of static properties on the ApplicationContext class that are used to define how the framework behaves. These are settings. When we run unit tests on the framework itself, we get some slightly inconsistent results because we are testing different scenarios that require changing the static properties. When other unit tests are in flight, this can change their behaviour in unintended ways, leading to transitory failures.

Potential Solution
Remove these static properties and instead keep these settings in one of the Options classes that are used for holding other settings. We can then inject these settings into the consumers who use the properties to enable a much more DI-centric, consistent experience. This will make the unit tests of the framework more consistent.

Users of the framework may also benefit from this change for the same reason, but perhaps to a lesser degree. It will be less common for people who are delivering end applications to have to run tests in all of these different scenarios. However, developers of other frameworks that extend CSLA may suffer from the same problem to a greater degree.

Additional Impacts
There are several configuration techniques. One of them fits a bit less well with the idea of these being properties of options; The code in the Csla.Configuration.CslaConfigurationOptions type (in the Csla\Configuration\Bind folder) is most affected by this change. We need to consider why this additional method of configuration is present, and whether this remains valuable and important, and thus how we would need to approach fixing this class.

Additional Context
Some of the failures we see in the Csla.Test project are as a result of this problem.

[rockfordlhotka]

I'm trying to replay my thinking on this. I think in v5 I tried to eliminate the static values and was unable to because there were a host of static methods across the CSLA API that rely on them, and changing them to instance properties/methods would have required changing all those static methods in the API into some sort of instance methods.

Lots of reflection helpers and that sort of thing iirc.

[TheCakeMonster]

Yes, that makes sense. I wonder how many of those issues will have diminished as a result of all of the work you did to move the framework from static classes and methods to instantiable classes and instance methods in order to support DI.

[TheCakeMonster]

Well, there are a few that would be hard to move. The following are out:
UseReflectionFallback
PropertyChangedMode
DefaultTransactionIsolationLevel, DefaultTransactionTimeoutInSeconds and DefaultTransactionAsyncFlowOption

I think all of the others are manageable, but for one thing: config binding via CslaConfigurationOptions. I'll need to have a think about how to do something similar to that, which is why I haven't dived in and made all of the changes today. I'll mull that over for a couple of days and see what I come up with by way of loading from configuration files.

[rockfordlhotka]

This is going to be a serious breaking change.

To accomplish this goal, it is necessary to rework (really to fix) the way the options and extension methods in Csla.Configuration are implemented. Some are correct, but some (especially for the data portal) are really not done right.

As a result, every app using DI will need to rework their AddCsla method call at app startup to use the new options graph structure.

Fortunately the changes should be isolated to something like Program.cs.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.