Last time we spoke generally about MVC and how it might apply to FileMaker. Today, we’ll take a look at one particular piece of MVC, the model.
Model
The model is basically a representation of the objects in your system and the business logic surrounding those objects. Sometimes we tend to think of these as simply the tables in our database, but this is only partially correct. They do indeed involve the tables and fields that make up your database, but it encompasses more than just that. It also encompasses any functionality necessary to create, modify, and extend these objects.
So, for example, if your database is about recipes and you need to add units of measure to your ingredients and allow the unit to change dynamically with new units created on the fly, you could add this functionality to the model of the recipe itself and everywhere you have a recipe, that functionality would be available (as permitted by the controller, but we’ll get into that later).
Let’s Get Real Here
Now, in the world of FileMaker the model is typically going to be the data tables themselves, the relationships that are useful to represent the data model, and the scripts used to create/edit/get/delete these objects, and layouts used by the scripts to manipulate the data (since adding and modifying data requires a context).
In terms of real world use, this can sometimes get tricky. The interface allows users to directly access and modify the data in a particular record and field. In this case we need to think of the layout as the view, FileMaker’s engine and security policy as the controller, and the data within the tables and their relationships as the model.
Many times accessing the data this way is extremely useful. But sometimes we don’t want a user to modify that model data directly. This may be because one piece of information is tied to another piece of data, or something needs to happen elsewhere in the system when that data is changed. Often times this is something of which the user is not aware.
The are various ways to approach this. One way to handle this is through script triggers. When a piece of data is modified on the layout, go do something to modify the other data. There are other techniques that basically accomplish the same thing. And at times this is helpful. But often times it is not. Here’s why.
Spaghetti Anyone?
What if you have that same data visible in multiple areas of the system. What if, in each area of the system, that data appears in a slightly different context? Do you have multiple scripts each modifying the other parts of the data from various contexts as necessary? You can easily end up with multiple ways of accomplishing the same thing.
FileMaker databases can become houses of invisible spaghetti strands connecting data every which way. It can still work, but let’s say that the business rules have changed (uncommon scenario? I think not). Will you remember all the places you need to change the process to accomodate the change in business rules? Maybe. Maybe not. How long will it take you to find everything?
Model It and Forget It… Sort of
Putting all this work in the model has the benefit that when business rules change that affect the model, you can change it in one place and one place only. Then you’re done.
Since you’ve changed the business rules in the model, and because your controllers are always calling the model to do the work (rather than handling it in it’s own way) you can rest assured that everything that needs to get done will get done. And it won’t take you forever to accomplish that.
Let’s Get Practical
Okay, okay, you see the benefits of using a model to handle data and business logic surrounding the data. Now, how does that actually work in FileMaker?
The practical side of what you actually do in FileMaker sometimes comes down to personal preference in development. Nevertheless, here’s how I typically do it (and at the end of our series on MVC, we’ll release a sample file illustrating things).
When it’s possible to use multiple files (and sometimes this is not), one file is used pretty much strictly for the model (the nature of FileMaker doesn’t always allow a completely strict separation, but most of the way). In it I create the tables and relationships that describe the model. Often times relationships are created purely for display purposes, and sometimes this is unavoidable, but in the model file I’m usually focused on describing the data in terms of the objects and their business rules.
I have a set of layouts, not directly accessible by a user, that are dedicated to handling model sorts of things. The layout context is dependent the model functionality for which the layout is used. The layouts themselves are extremely light weight, containing no more fields and objects than is necessary. Some objects have names, which assigns them a meaning within the context of particular model functionality.
I setup a script folder for each entity that I want to model. Inside these folders are the scripts that handle things such as creating, retrieving information, modifying, and removing pieces of the model. The scripts themselves are typically passed parameters that give them all the information they need to be self-sustaining. That is, they can go, find their own context, perform their own actions, all without any dependence on where they were called from (the core of separating model from controller and view).
Setting things up this way, I can call the same model functionality from anywhere within my system and get the same functionality. If I need to change how it works, I make that change to the model (in terms of tables, layouts, and scripts doing the model work), and instantly every part of the system accessing the model gets that new or modified functionality.
For straightforward, simple solutions (a few tables, very little scripting, fairly flat concepts), this is often times overkill. But many of the systems we work on (and probably you too) are complex, with lots of system interaction. Following an MVC pattern allows us to model the business logic once, and use it in multiple places. It also allows us to know that changes made to the model will work everywhere.
Next Time
So, this time we’ve looked at what the model component of MVC is and how it works within FileMaker. Next time we’ll move on to the next letter of our acronym, C, or the controller.
Your Turn
You’ve just read our thoughts on FileMaker and the model portion of the MVC pattern. Now it’s your turn to let us know what you think. We don’t pretend to have all the answers related to MVC and FileMaker, so we’re interested in our take on these things. Feel free to drop a comment and let us know your thoughts!
