#Model-View-Presenter Architecture : MonoBehaviour or POCO (Plain Old Class Object) ?

1 messages · Page 1 of 1 (latest)

elder lintel
#

I'd like to use an MVP architecture for my Unity project as presented in Unity's e-book "Level up your code with game programming patterns".
I noticed that the Model and Presenter classes are made as MonoBehaviours. I was wondering about making the Model and Presenter classes as POCOs to make them easily serializable/deserializable for game saving and loading, with Presenter classes being instantiated as needed to represent the corresponding Model. There's also the benefit of not having all the overhead of a MonoBehaviour, particularly for the Presenter classes. Does this make sense? Are there any potential pitfalls to doing it this way?

#

Model-View-Presenter Architecture : MonoBehaviour or POCO (Plain Old Class Object) ?

tardy ocean
#

If you want to serialize data, you might consider using the Monobehaviour.

#

Otherwise, you will have a harder time to serialize data.

#

Alternatively, you can use SerializeReferene, but I do not suggest to use it as you might want to reseuse your components.

#

You could also use ScriptableObject, but those should only be used as immutable.

#

Which means, that you would create a "Factory".

elder lintel
#

If you want to serialize data, you might consider using the Monobehaviour.
My understanding is that MonoBehaviour object is not normally serializable to JSON. Not easily anyway. Some solutions I've found online say to use the Memento pattern, or using the third-party Vexe Framework (VFW). There's also Unity's documentation on Script serialization (https://docs.unity3d.com/Manual/script-Serialization.html#SerializationRules), but it seems to produce more questions than answers to my problem.

craggy wedge
#

I would on the contrary suggest you to look into the reactive architecture based on signals, something that gained huge traction in the weddev recently and what people working in Unity also successfully implemented.

Vast majority of people I follow and who had experience with MVP/MVVM/MVC would NOT recommend this pattern. Conceptually it sounds good, but practically, it's a real PITA. It can be an even bigger PITA in unity, where even basic programming using universal programming patterns is a constant battle with the engine.

elder lintel
#

@craggy wedge Are there any existing frameworks that implement this? Our project already uses Zenject for DI.

#

Google search shows me UniRx.

craggy wedge
#

UniRx is also something worth investigating

#

The added beauty of such an architecture is that it is pretty simple to implement it even from scratch

elder lintel
#

Thanks!

#

@craggy wedge Wait, I see a lot of talk regarding DOTS and ECS when I look up Unity reactivity frameworks. Are they inherently related? I'm a bit apprehensive about jumping into DOTS/ECS. Can I use a reactivity framework in a classic Unity GameObjects paradigm?

craggy wedge
#

Mentioned reactivity system is not coupled to the ECS. It is a universal programming pattern which can be implemented in vanilla C#, JS and others. Maybe it's mentioned in ECS because just like ECS promotes a declarative/reactive data oriented design over imperative statefull design present in MonoBehaviors, this reactivity system is just a model that can be easily integrated and successfully used in similar context.