If you’ve been around FileMaker for a little while you’ve probably come across the idea of the separation model. Basically, this concept says that you ought to separate your data and your interface files. This allows you to change the interface wit
hout having to touch the data file, which can improve subsequent version deployments.
There are other benefits as well, but this post is not about the separation model. Instead, it’s about the MVC pattern. I was familiar with this pattern before attending the PauseOnError conference out in Portland a while back, but after a session with Ernest Koe and Corn Walker of Proof Group I started to visualize how it might fit into FileMaker development. So what is MVC?
What is MVC?
MVC (model/view/controller) is a concept that separates not only the data (model) from the interface (view), but adds one more level of separation – control. The model is where business logic and data reside, the controller is sort of like the traffic cop, taking input and passing it around appropriately, and the view is what finally gets the information to the user and gets input back for the controller. Together these three concepts structure how a system is developed.
MVC is very popular in the web development world and the iOS platform (among others). While these environments allow a more rigid adherence to the pattern, FileMaker is different. That’s because FileMaker blurs the lines between concepts.
Many times this blurring of the line is extremely helpful (think about how much time it took you to put a field on a layout and let the user change the data in that field… other platforms don’t have it that simple). It’s what FileMaker gives us “for free.” But that also means we have to consider how MVC works in the FileMaker environment.
Why MVC?
So the big question is, Why does this matter? And that is an important question. It might be easiest to explain why by asking a few different questions.
One Can Dream
Wouldn’t it be nice if, when looking at a system, you knew that if you made a change in one place nothing else would break? Wouldn’t it be nice if a customer asks for a new feature, you could simply extend existing scripts and leverage code you’ve already developed? Wouldn’t it be nice if business logic changed, you knew exactly where to find that logic (and it existed in one place)? Wouldn’t it be nice if you could consistently control what functionality of the system users could perform?
MVC To The Rescue
These are the areas where MVC helps. By separating out data and business logic into one place, when changes occur you know exactly where to go. You also know that if you change the logic here, you’ve changed the logic throughout the whole system. You no longer have to go hunting through scripts, layouts, and custom functions to make sure you found everything. If you need to control where a user can go and what functions they can perform, beyond what FileMaker’s native security can dictate, you simply alter the controller and know that you’ve fixed it everywhere.
Additionally, if a new developer is following the pattern, then they should be able to more quickly understand what is going on in a system as a whole. Interchanging developers on a system is a useful thing.
So MVC in FileMaker, Really?
If you’ve followed up to this point, chances are you’re interested in how MVC fits into the FileMaker paradigm. Since, as we’ve seen, there is no clear seperation of model, view, and controller within FileMaker, it might help to look at each of these individually. So, in the next few posts, we’ll take a peek and see how each concept relates to FileMaker specifically.
Your Turn
You’ve just read about MVC and FileMaker. Now it’s your turn. We’re interested in your thoughts, so feel free to leave us a comment and let us know what you think. Go on, don’t be shy, it’s easy!
