I have been searching since day one for an architecture that can make designing, extending and maintaining a complex FileMaker system easier. I have yet to find one. Sometimes I think FileMaker is too flexible. There are too many easy ways to do things that will absolutely cause you myriads of grief later. I have tried several times to develop my own frameworks, but they always left me feeling like it was too much work.

I have been talking over some new ideas about this problem with Ernest Koe of the Proof Group. It appears that his team of FM bright spots has reached a similar set of conclusions about how to apply some order to a complex FileMaker system. I hope that this series of posts will help to flesh out some of the ideas we have been kicking around.

The one architecture that gets discussed a lot is the "Separation Model". I have been a proponent of this model in the past. I have used it many times. I started working with it way back in the FM5 days after seeing Colleen Hamersely present on it at DevCon. The advent of FileMaker 7 made this model a bit easier to swallow, but after the newness wore off, I found myself with a bad aftertaste. There are just far too many compromises to make. A good framework should remove ambiguities. I find the separation model brings up more questions than it answers.

Using the Separation Model does have the effect of reducing, but in most cases not eliminating, the need to do data imports when upgrading systems. Certain kinds of projects can benefit from easier upgrades, but not all of them. Custom in-house solutions, for example, don't gain much from having easier upgrades. Couple this with the fact that you have to jump through all kinds of hoops, make lots of compromises, and weaken the readability of the code just to make this work. In my opinion, you quickly reach the point of diminishing returns.

One of the many problems with the Separation Model is the fact that it frowns on the use of FileMaker calculation fields. Calcs are one of the things that make FileMaker easier to use. In fact the more strictly you apply separation, the more you loose some FileMaker inherent strengths like calculation fields and record locking.

Recently, I have begun a serious journey into other programming languages. While doing so, I started hearing about a Design Pattern called Model, View, Controllerr (MVC). MVC separates code into three "areas." I am specifically NOT referring to them as three "layers."

The Model is a representation of the data, the View is what the user sees and interacts with, and the Controller mediates between the two. There is not a strict separation into layers. In fact, an MVC system is often made up a bunch of components that are also built using MVC.

Although at first blush the three areas look a lot like the Data, Logic, and Presentation layers of the Separation Model, they are different. Those differences have led me to start exploring MVC as viable Design Pattern for FileMaker.

What follows is my current approach to designing a FileMaker System using MVC, and why I think it is better than following the Separation Model. It is by no means complete, and will most likely change. In fact, I hope it does.

I am going to start by examining the Model (the "M" of MVC). MVC says that the "Model" is a representation of the data. In object oriented languages the model is often expressed as a class with properties and methods. In FileMaker terms the Model is expressed most often as TO's and Fields. Scripts and layouts can also belong to the Model, but I will leave that part for later.

What is the difference between calling something part of the Model or part of the Data Layer? First, the term Data Layer has a bunch of connotations attached to it that are difficult to fit into the FM world. Take normalization for example. There are many times that you simply must store data in more than one place for performance reasons. Pure separation says this is bad idea. Practicality says we have to do it. Another example is using calculated container fields to display something to the user. Pure separation says bad idea. FileMaker makes this super simple. It is one of its strengths.

Diving into the UI graphics issue a bit more, lets look at how the Model of MVC handles this problem. In an MVC paradigm the Controller might ask the model to "get" the UI graphic. The controller would then give the graphic to the View and say "display this graphic". In MVC, the UI graphic is just another attribute ( think FileMaker Field) of the Object (think FileMaker record). The fact that the Graphic lives in the same space the rest of the attributes is ok.

Getting very real about this one for a second, lets take the example of a customer record with a past due balance. The programmer decides that if the customer has a past due balance then they should get a big red Flag placed next to their name everywhere the name appears in the system.

Using the separation model, I have to put that logic onto every single layout in my system. I can do this by adding a bunch of TOs to my already complex relationship graph or doing some conditional formatting on each layout. Either way I have spread the logic out all over the place.

The MVC approach would view the big red flag as most likely belonging to the Model. The Model is the holder of all attributes and common functions that have to do with a particular entity ( ie record in a table). Therefore it makes perfect sense to simply create a calculation field that "gets" the correct graphic. The logic behind the displaying of the graphic resides in one place, the Model.

This resolved one of the long standing problems I had with using Separation. There are lots of types of Logic that BELONG to the data. They only make sense in the context of the data. They have no viable home anywhere else. Think of scenarios like "if this field value changes to 'A' make this other field 'A + 1'". Where else could that go, but tightly associated with the data?

MVC says, "Yup put that stuff where it belongs, in the Model."

This is not a perfect fit. We have yet to get into scripts and layouts, and how those almost have to play a role in the Model sometimes. There are other issues as well. But I do feel like MVC makes more sense as a Design Pattern then the Separation Model.

As you can probably guess Controllers are almost always expressed as FileMaker Scripts. And Views are almost always expressed as FileMaker layouts or parts of layouts. I hope to cover each of these in an other post in the very near future.

stay tuned

UPDATE:
Part 2 is here