Model Conventions


This page teaches about certain conventions that one should consider when using models in IoC+. There are a ton of different use cases for models and these conventions should give you some do’s and don’ts.

In this page we assume you’ve read the models tutorial first. If this is the first time using IoC+, we suggest to read the introduction first.

No models in Mediators

Models, as thought in the models tutorial, are there to store data for later use. It is conventional to only inject models in commands and not in mediators. This way we have clear distinctions in our codebase.

Views only as interfaces

Next to storing simple data types in models like integers and strings we can also store references to views. This could be handy to query some information that is only available for a monobehaviour. Directly storing a view in a model is bad practice however, as commands cannot be unit tested properly and the monobehaviour properties of the view will allow commands to do whatever they’d like. Therefore we have a convention to only store views in models as an interface.

Naming Models

Naming your models correctly will help you remember what data is stored in which model. Over the course of using IoC+, we’ve come up with three types of models: the Model, the Reference and the Status.

The “Model” Model

By ending a model name with the “Model” postfix we tell ourselves that we use it as a serializable, persistent data object.

public class PlayerModel {
    public string Username;

The values of this model type are usually loaded and set by a service on startup and rarely changes throughout the session. When it does have to change however, the service should probably be notified first.

The “Reference” Model

By ending a model name with the “Reference” postfix we tell ourselves that we use it as a reference to an interface of a view.

public interface IPlayer {
    Vector3 Position { get; }

public class PlayerReference {
    public IPlayer Instance;

In this example we see the IPlayer interface, which will probably be implemented by the PlayerView class. The position is made accessible by the interface as this is information that is inherently stored in the monobehaviour and wouldn’t make sense to store in a separate model. The reference to the interface is usually set by the same command that instantiates the view.

The “Status” Model

By ending a model name with the “Status” postfix we tell ourselves that we use it as a data object that keeps track of values that change frequently throughout the session.

public class PlayerStatus {
    public float Health;

In a lot of cases, the fields of a status model come along with a change signal. In this example, a PlayerHealthChangedSignal could be dispatched manually in each command that changes this model’s health value. This way we can potentially bind commands to, for example, update a health-bar. The values of a status model are usually set once when the game starts and updated by commands throughout the session.