koobas.hobune.stream
How do you organize your own "framework" code?
How do you organize that logic code that is not explicitly bound to a view?
While I try to work with behaviors as much as I can to extend the functionality of a view, I instead use pure c# classes to describe my own framework.
All these classes can be created through an IoC container, but this is another story. The problem is I wonder if you use MonoBehaviour managers, that are those classes that do not have a view and are used to manage external objects.
If so, I would like to know in which GameObject you put these "manager" MonoBehaviour classes.
yeah would be usefull know some more ways to organize unity scripts in some (not only nice) fashion to improve workflow.
I would put those kind of scripts on a new empty GameObject (call it eg. Application). I think that's what you are asking about but I'm not sure I understand you completely. Could you please explain what you mean by code being "bound to a view"?
sure, for View a mean a Renderable GameObject (or a Camera). $$anonymous$$y impression is that $$anonymous$$onoBehaviour should be used only if meant to extend the behaviour of a Renderable object otherwise I could use a normal class. Thanks for the answer btw.
