MVC and FileMaker, Wrapping It Up

Over the past several posts we’ve discussed MVC and FileMaker. We’ve talked about why you ought to consider implementing this pattern into your system. We’ve looked at each piece of MVC (model, view, and controller) and how it might work within FileMaker. Hopefully, you’ve seen some of the benefits and practicality of using MVC in FileMaker.

Separation Model

One further little tip here. When you combine the power of MVC with the power of the separation model you get some additional benefits.

The data file can act almost completely as your model. You can keep the file hidden, and when you perform scripts within the file it is invisible to the user (no more hiding off-screen windows or window freezes and layout changes to do the model’s background work). The relationships in this file only have to be the ones that relate to how your model works, and they can usually be kept very simple and clean without requiring the waters to get muddied by relationships for view or control work.

The interface file only needs the relationships that will make the views work properly. If no view of a particular model relationship is necessary, don’t add it. Your scripts can all be contextualized for the layouts in the interface, with no need to worry about the context for model activity.

Example

We’ve talked about giving an example file to highlight some of what we’ve discussed. Well we’ve put a little time and have a sample file ready. It’s a barebones look at how MVC might be implemented in FileMaker. As such, it’s not intended to be a full functioning system. For example, it needs better error trapping and handling. Also, as an demonstration file, the system and it’s functionality is a bit contrived. It’s not trying to show an ideal interface, but rather serve as a platform to illustrate some of the pieces of MVC.

We implemented an abstraction component in our model. This is a set of scripts that does a lot of the heavy lifting for you. It just requires layouts set up for model use (basically having an id name on the object that is the id for the table) and it handles obtaining and resolving context for the model, etc. That isn’t necessary for an MVC pattern, but it’s something we’ve incorporated into some of our systems to make things a bit easier.

So, without further ado, here’s the FileMaker demo file for your MVC enjoyment.

As with any development team, our implementation of MVC seems to improve and get more refined each time we do it. So this is, as they say, a work in progress. We’d love to hear your thoughts on how it could be improved.

Bottom Line

The MVC pattern is something we are adopting here in much of our work. It keeps things more organized, allows us to make changes in one place and have that change work everywhere, and it makes the process of adding functionality simpler. Multiple developers working on the same system can more easily understand what is happening within any given system if they both follow the MVC pattern. It seems to just make sense.

Your Turn

You’ve just completed reading our series on MVC and FileMaker. We tried to make it clear at the beginning that we don’t know everything there is to know about the subject and would love to hear from you. So, it’s your turn again. What do you think?