Reason 7. is wrong.

[soraphis]

AntiScriptableObjectArchitecture/README.md

Lines 27 to 28 in 11f7e65

	## Reason 7. You cannot turn off Domain/Scene Reload
	According to [Unity's Document](https://docs.unity3d.com/Manual/SceneReloading.html), when you turn off Domain and Scene reloading for better performance of Play Mode, your Scriptable Object will **keep the value**. That's the price of messing asset with mutable values. Who on earth will know what will happen when your core logic does not reset it's value? You may never be able to turn them off.

This has nothing to do with domain reload. In the editor ScriptableObjects always kept their values - not so in builds.

IIRC on UnityAtoms we addressed the issue and are resetting the ScriptableObjects accordingly event if domain reload is disabled. Not sure if we handled every edge case, but it surely is possible to do so!

[cathei]

What I read from Unity Scene reloading document says it is relevant.

Disabling Scene Reload should have minimal side effects on your project. However, because Scene Reloading is tightly connected to Domain Reload, there are a couple of important differences:

ScriptableObject and MonoBehaviour fields that are not serialized into the build ([NonSerialized], private, or internal) keep their values. This is because Unity does not recreate existing objects and does not call constructors. Additionally, Unity converts null private and internal fields of array/List type to an empty array/List object during Domain Reload and stay non-null for runtime (non-Editor) scripts.

But you’re implying they are keeping their value regardless. Anyways, if you need to install some other plug-in or additional step for it, point still stands.

[soraphis]

if you need to install some other plug-in or additional step for it, point still stands.

no, you just have to code your scriptable object architecture properly (UnityAtoms, which i mentioned is a SO-Architecture library, no further plugin needed). But you also have to be careful with your MonoBehaviour scripts if you disable domain reloading.

ALSO same point stands for every other solution. You also have to create a WORKING dependency injection system, if you want to use DI instead of SO-A.

having coded something badly is not really an argument against SO-A, but is more like a general advice.

[cathei]

ALSO same point stands for every other solution. You also have to create a WORKING dependency injection system, if you want to use DI instead of SO-A.

That is true :)

having coded something badly is not really an argument against SO-A, but is more like a general advice.

Yes, but I mention it because it’s easier to create those errors when you use SO. MonoBehaviour usually reset their states through lifecycle events and if you use regular C# object you would just create new instance without garbage value.