Dated: 2018–03–28

The other day, I typed “Flutter” “MVC” into Google (quotes gives you a ‘Verbatim’ result), and got the typical suggestions to use third-party libraries. They do have their place, but I just wanted to implement such a design pattern in a few ‘native’ classes — in keeping with the good ol’ ‘KISS principle.’

As you know, like other design patterns, MVC aims to decouple its three major components allowing for efficient code reuse and parallel development. Like most things, it generally ‘makes Life easier’ if you break things down into its separate working parts. In most cases, the bigger the software application and/or its complexity; the bigger the importance to implement such a pattern.

MVC in a simple nutshell:

Controller controls what data is displayed. View is concerned with how the data is displayed. Model is the Controller’s source for data. Of course, not necessarily the data eventually displayed. The Controller is the brains of the operation. It identifies the user’s input, dictates how the model’s data source needs to change (as a result of that input for example), and what data is eventually displayed in the chosen View. The View and the Model are each tightly coupled to the Controller (i.e. The View knows how to ‘talk to’ the Controller, and the Controller knows how to ‘talk to’ the Model ), ideally however, each has no idea of the other’s existence. On the whole, the View and Model do worked together, but indirectly — through the Controller. This allows one, for example, to switch out the Model and put in a different one providing a completely different source for the data. Again ideally, the Model would only have to conform to the API requirements so the Controller can ‘talk to’ it correctly. No need or desire to change the Controller since we may return to the original Model, introduce multiple Models, etc. So too with the View. One should be able to switch out the View at will with little consequence.

View knows how to ‘talk to’ the Controller, and the Controller knows how to ‘talk to’ the Model.

Dependency Injection

I also wanted an approach that would intrinsically support DI as it too is a recognized technique for reducing coupling. Frankly, you can’t get more intrinsic than passing the three MVC components to each other as parameters: