devNotes 6-25-16 ioc – amvcc or application-model-view-controller-component



toptal-blog-image-1438268968391.2-56f489174107c172be051385f7d274e8 (1)



  • Hold the application’s core data and state, such as user performance, statistics, vitals.
  • Serialize, deserialize, and/or convert between types.
  • Load/save data (locally or on the web).
  • Notify Controllers of the progress of operations.
  • Store the State for the Finite State Machine.
  • Never access Views.


  • Can get data from Models in order to represent up-to-date game state to the user. For example, a View method player.Run() can internally use model.speed to manifest the player abilities.
  • Should never mutate Models.
  • Strictly implements the functionalities of its class. For example:
    • A PlayerView should not implement input detection or modify the Game State.
    • A View should act as a black box that has an interface, and notifies of important events.
    • Does not store core data (like speed, health, lives,…).


  • Do not store core data.
  • Can sometimes filter notifications from undesired Views.
  • Update and use the Model’s data.
  • Manages Unity’s scene workflow.







As shown in the example above, when the ball hits the ground its view executes app.controller.OnBallGroundHit() which is a method. It isn’t, by any means, “wrong” to do that for all notifications in the application. However, in my experience, I’ve achieved better results using a simple notification system implemented in the AMVCC Application class.

To implement that, let’s update the layout of the BounceApplication to be:


Next, we need a new script where all developers will add the notification event’s names, which can be dispatched during execution.


It is easy to see that, this way, the code legibility is improved because developers don’t need to search all over the source code for controller.OnSomethingComplexName methods in order understand what kind of actions can happen during execution. By only checking one file, it is possible to understand the overall behaviour of the application.

Now, we only need to adapt the BallView and BounceController to handle this new system.


Bigger projects will have a lot of notifications. So, to avoid getting a big switch-case structure, it is advisable to create different controllers and make them handle different notification scopes.

AMVCC in the Real World

This example has shown a simple use case for the AMVCC pattern. Adjusting your way of thinking in terms of the three elements of MVC, and learning to visualize the entities as an ordered hierarchy, are the skills that ought to be polished.

In bigger projects, developers will be faced with more complex scenarios and doubts about whether something should be a View or a Controller, or if a given class should be more thoroughly separated in smaller ones.

Rules of Thumb

There isn’t any “Universal Guide for MVC sorting” anywhere. But there are some simple rules that I typically follow to help me determine whether to define something as a Model, View, or Controller, and also when to split a given class in smaller pieces.

Usually this happens organically while I think about the software architecture or during scripting.