Model-Runtime
This is part of the video tutorials about the contribution Model-Runtime-Editor design pattern
9 Likes
Thank you for this still relevant source, I guess I watch it once a year or so :) I’d like to ask something - so if I understand it right, for each emitter there is a model and a runtime. The changes made by the editor is both applied to the properties of the model (a record) and the runtime (a class). We need the synchronization to make sure that whenever the model changes, the same changes are also applied to the concurrent runtime object, so they are in sync.
What is the exact usecase to structure the application like this, I mean, at which point should one decide to seperate model and runtime and not simply have an update operation in the model itself? Is it to combine the best of both worlds (records and classes) in the application? So to be able to change the object from anywhere in the application (using the class) but also to provide the snapshots and to be able to implement undo and redo (using the record)?
Technically model and runtime splits on any modern programming pattern e.g. MVC, MVVM, ECS, the key concept of this you have to bare in mind that the model is serialiseble, e.g. it does not includes any methods and used to save and restore state. The controller - the runtime is an object that performs operations (includes methods).
This quite a bare description but that probably the key concept behind the methodologies to write software architecture.
3 Likes
Thank you very much for your answer! I was also thinking about the comparison to MVC, but until now I thought the equivalents would be more like that:
Model = Model
View = Runtime (because the runtime is the thing being displayed?)
Controller = Editor
Now you’re writing the controller would be the runtime… I am confused. Is is even possible to make such a side by side comparison?