Last time we examined the view portion of MVC and how that might look in FileMaker. Today we’ll take a look at the controller.
Controller
I like to think of the controller as the middle man between the model and the view. This is the place where the pieces get connected.
For example, let’s say you’re building a system that inventories computers and their associated parts. You want to allow the user to add a new part to the list of available parts to associate with a computer.
In this scenario, the controller is the part of the system that takes that request in from the view (who got it from the user as discussed in our last post), and sends it, along with all necessary information, to the model to have that part created. If it doesn’t have all the information it needs for the model, it will go back to the view and have it get all that information from the user, and send it back. Once the model has done it’s work, the controller is notified with the result. Typically, the controller will then tell the view to display the results (if necessary).
The benefit of doing things this way is what is called loose coupling. It allows the model to do things however it wants to, and the view to get and display information in it’s own way, without affecting each other. The controller manages the interaction between these pieces so that the model and the view are not in any way dependent on each other.
So, you can easily change how you get the information in the view (layouts, custom dialogs, etc.), without impacting how you manipulate that information in the model. Conversely, you can change how your model works without impacting how the information is displayed and obtained. The controller, then, is the linkage between them.
Um, FileMaker?
Clearly, the goal of this series of posts isn’t to explain MVC completely, but to show how it might work with FileMaker. It makes sense, then, to see how the controller might function in FileMaker.
In many cases, the layout is acting as the view, getting and displaying information and requests from the user. Sometimes the view is a script that has a custom dialog obtaining information from the user, or something similar. Usually I will create a script to be the controller. The view will call this controller script (or a button will perform the script) with the appropriate information that it needs.
In FileMaker context is important. So I tend to make the controller context specific. That is, I will make a controller script for a specific context, so that it understands where it’s data is to be found. It will then pass the appropriate information to the model so that it can do it’s work (context free) and accept the response (resulting information, success, failure, errors, etc.) and give that back to the view (usually in the form of some view script that handles displaying the data through a layout, popup, etc.).
Typically, I have multiple small controller scripts. The helpful mantra that is out there in the world of MVC discussions is “Fat model, Skinny controller” – meaning, keep your controller light weight and let the model do all the heavy lifting. So I try to keep business logic out of my controllers and put it in the model. That means that my controller scripts are basically connecting scripts. They call the model and view scripts that are necessary to perform the task that the user requested, but they don’t actually perform the task itself.
I Live In The Real World
Yes, we all live in the real world. Theoretical concepts are helpful and important, but when the finger hits the keyboard (or mouse!) – that’s when it gets real. I say that to say this (I love that segue, don’t you?): the implementation of MVC in FileMaker can’t be strict. That is, there is room for interpretation as to what goes where and how things get done.
The most important thing to remember is that MVC is trying to provide loose coupling. The reason for employing it is to make changes and extensions easier by keeping the view and the model separate. Try to keep the controller as that in between piece, it has knowledge of the view and the model while the latter doesn’t understand the former nor each other.
Next Time
Next time we intend to wrap up the series with a discussion of putting it all together. Hopefully, as we’ve gone through the parts, you can see how they connect (we’ve tried to make that clear), but we’ll try to tie any loose parts together (pun intended). Also, we plan on having a small demo file that begins to illustrate some of the concepts we’ve discussed.
Your Turn
We’ve just talked about the controller component of MVC. As we’ve being saying all along, we don’t pretend to have it all figured out and would love to hear your thoughts. So, feel free to let us know by leaving a comment below!
