An introduction to MVC

The objective of the MVC paradigm is to enforce loose coupling between the representation of information and how the user interacts with it, so the developer can more easily change one without breaking the other.

By loose coupling I mean that your application is divided into units (that in the MVC paradigm we call models, views and controllers) that are not dependent on each other in a hardcoded way. This means separating the way things are stored and retrieved (aka model) from your business logic (aka controller) from the way you display your application (aka view). If you follow this separation, you will be able to change each unit with minimal change to the surrounding units.

To achieve this separation, we should follow the law of Demeter which states that each of our application units should only have limited knowledge about the other units and restrict its interactions to its closest friends. For example, in a complex application with an address book module and a project management module, each module should restrict its interactions to themselves. The project management module should not go changing the data from the address book module without talking to it. The law of Demeter helps us avoid the difficult debugging problem of figuring out where something was changed.

We can think of MVC as a way to untangle our stacks moving from the usual spaghetti-approaching state towards a neat and organized future. Since we’re speaking about stacks, lets draw out some plans to explain how MVC applies to a project. As we progress in this book we’ll build a simple address book example that will be divided into units called model, view, controller and libraries. Each of these units is a different stack and will deal with a distinct problem.

MVC & OOP: The MVC paradigm was created alongside the Object-Oriented Programming which is one of the main paradigms to approach programing. LiveCode is not an OOP language in the classical sense as understood by SmallTalk developers, but that does not mean we can’t leverage what we can from the MVC way of doing things when creating our own applications.

MVC in 20 seconds

The model

Our address book model will load, save and manipulate address book contacts data. We will define an API that the other units will use. How we implement this contact manipulation is of no concern to them. We could even have more than one model for the same data type but with different implementation, such as a model that saves to a database, a model that saves to text files, and a model that saves to a remote server. As long as we implement the same public API, we can change the internals of the model without touching the other units. In the classic MVC implementation, the Model will notify interested parties if the data changes.

The controller

The controller is a stack that holds your business logic. While the model knows how to manipulate contact data, it doesn’t know why or when it should manipulate it. The controller talks to the model, like a transit cop directing traffic to and from the model to the other units.

In the classic MVC implementation, the controller gets input from keyboard and mouse or whatever input gizmo you are using and decide what to do with it. It talks directly to the model, telling it what it should do the data. It can also talk directly to the view, since some input may require stuff in the view to change.

The view

The view is the presentation layer with your cards and controls. The user sees and interacts with the view and the view talks only to the controller, which talks to the model.

This way you can try different views and layouts without touching your business logic because that code is on the controller. When you’re building cross-platform applications, you can build multiple views to create interfaces suitable for the various form factors you’re deploying to, like desktop, tablets, and smartphones, all from a single application source.

In traditional MVC implementations, the model uses broadcasting techniques to inform the views when data changes. In this loose coupling, the model has no idea what inside the view needs changing; it is just broadcast to all interested parties that they should act upon data change.

Libraries

It is good practice to build code that is reusable beyond your current application development. Libraries are not tied to the business logic of your application, making them the most reusable pieces of our softwares. The more generic looking code that you can build into libraries, the easier your development will be.

As an example, suppose you have a function that picks a name like andré alves garzia and converts it to TitleCase like André Alves Garzia. This function is useful for the address book application and many other applications, so it could be part of a library and reused in other projects.

Summary

This was just an at a glance introduction to MVC. Each chapter now will dive deeper into one of these concepts, starting with models. By each chapter’s end, we’ll have one unit ready and be closer to the finished address book application. This small chapter had a bunch of links in it. You should check them all. Now, lets see what how we make models.