MVC and FileMaker?

By July 30, 2012November 30th, 2022Development, FileMaker, MVC

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 without 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!

Court Bowman

Author Court Bowman

Court Bowman has been working with in the IT field his whole life, working as a network engineer, database developer in Oracle and Progress and as a IT director for several firms. He has been working with FileMaker Pro since version 2 and has been a reoccurring speaker at the FileMaker developer conference. Apart from his expertise in FileMaker Pro he has experience in system architecture and design, data modeling and database architecture. He also has years of experience as a process and workflow consultant and has helped with the design and deployment of hundreds of systems in FileMaker and on the web.

More posts by Court Bowman

Join the discussion 4 Comments

  • Brian Schick says:

    Fantastic article – insightful and very promising. Looking forward to more 😉

  • Arild Schonberg says:

    YES! I love this start. I also heard Ernest Koe (what a nice guy) discuss MVC at PauseOnError in New York and started to get a grasp of what this could mean in the world of FileMaker. 

    – Number of files. 
    I think we should not be as afraid to take separation to a new level. Separating Data and Logic is the first step of separation. From FMP7 we were taught to include all tables to make development easier. But is it really?
    Within a database there may be specific tasks you want to separate from the Model (data) and what the user needs to see, the View (logic). Import and calculation of data is one thing that may be done by the server and this logic should not need to reside within the same file as the user logic. Reports, automatic emails and other “behind the scenes” actions are also parts of logic that easier can be upgraded when not in the same Logic file (UI file) as the Login file used by every day users. 

    Show us some more Bowman, you are on to something fundamentally important
    Kind regards, Arild Schonberg

  • Bruce Robertson says:

    Thanks for posting this. I’d like to see more also. Particularly – example files, if only skeletal. The Portland POE/Ernest Koe video doesn’t work well for me. The audio is not clear. I can see that the discussion might have been great but it needs to be summarized.

Leave a Reply

All rights reserved Cleveland Consulting.