Entitas vs. MVC & MVVM
The first and the most obvious difference is MVC & MVVM are OO patterns. Entitas is Data Oriented.
But this is all fuzz, lets get more concrete. OO patterns are mainly about separation of concerns. In MVC we identify three disjoint concerns.
- Representation of data (View)
- Storing and transforming data (Model)
- Changing representation and stored data due to user interaction (Controller)
This is the idea. In reality those boundaries are shifting. In most MVC libraries View has it’s own model due to complexity and performance optimisation. Model becomes more about storing and retrieving user state (e.g. connection to data base or BackEnd), and Controller is an undefined massive thing where we can dump various functionality.
To address the problem of View having it’s own model, here come MVVM to the rescue. We still have Model which holds user state. We have View which renders information and we add another abstraction ViewModel. ViewModel reflects the runtime data which we don’t need in Model, because it only reflects current visual needs. It is transient and we don’t want to store it as user state in Model. Why do we need this abstraction? Can’t we just access Views internal model? Well in most of the cases we use MVC library which own the View state and encapsulates it. By introduction of ViewModel we create redundant representation, which we have under control and can reshape independently of 3rd party library.
Now what about Entitas. Entitas is all about data representation. In my previous blog post Games, Data and Entitas I described three types of data that a game can have. Entitas represents any runtime state you can have. Due to it’s flexibility we can have user state (Model) and transient representation related state (ViewModel) on the same entity. Entity is just a bag of components and therefor we don’t have to be strict about boundaries. In OOP the M, V and C are defined as classes and there for they are fragile, when we want to change them. I dedicated a whole blog series on this matter. In Entitas only Components are reflected as classes, this gives us a great amount of flexibility.
Back to the main topic. It is important to respect single responsibility principal when we implement systems. The individual system should be dependent on a small subset of components. It doesn’t care, if there are more components inside a given entity. This is basically what makes Entitas Data Oriented and not Object Oriented.
How should we incorporate Entitas when working with MVC libraries?
Model and ViewModel is described with entities. A Controller has two responsibilities.
- It creates entities on user interaction.
- It exposes API which enables a System to change the View.
Now we can have systems which react on user interaction entities and call the APIs exposed by Controllers to change the View.
We can also make a shortcut by introducing a third responsibility to Controller.
3. It can observer on Entity Group changes and change the view directly.
I implemented both strategies in my current project and must say that the first strategy is much more robust and easier to reason about. The second implementation is less code, because you don’t have to keep references to controllers and controllers become self sustained, but it becomes complex when the number of such self sustained Controllers grow and they listen to same entity changes. In Entitas, a reactive system is executed in order and aggregates changes. An observer however is executed directly and if you have multiple observers for one event, the order is non deterministic. This is what introduce bugs and makes reasoning much harder.