Is the advice in Matt Petrowsky's Video correct?

[Toby B]

I just watch the two part series of video on ISO Filemaker Magazine's website that discusses the Separation Model. See link below:

http://www.filemakermagazine.com/videos/the-separation-model-breaking-up-your-data-and-interface.html

My question is ... is his advice still valid. In particular his warnings on the difficulties in displaying calculated data in portals?

The only reason I am questioning it is because these video were released back in Oct 2004 which presumably meant he was talking about how difficult it was under v7. Has version 8.5 made his concerns redundant?

I am considering using a three tier separation model ( Data / Logic / Interface ) due to the fact that I can more easily send an updated interface file to all my customers using the solution (ie. bug fixes, additional features, etc) and re-purpose / tailor the logic layer for each new customer if need be. All with out ever having to run an export/import cycle.

From what I have researched on this topic I think I can combine the reporting layouts and derived data calculations into the logic layer. Which would make this the only customer-specific part of the entire solution.

Does anyone who has seen his videos and has had experience in implementing separation-model solutions have an opinion?

Toby

[Vaughan]

"...All with out ever having to run an export/import cycle."

Any changes to the data structure of the data or logic layers will require export/imports.

[Toby B]

I'm sorry Vaughan but I am a little confused as to why I would have to perform an import cycle on my Logic layer.

Are you referring to the "synchronisation" of the IDs with the data tables? I was planning on including that process in a startup script that may incorporate the List function and some custom functions I have seen that compare two lists adding any missing IDs to the logic table.

My understanding was that I should be placing all data in the data layer, and that the logic layer should be there for derived data that I can write back into the data layer.

This brings me to another point which is related to Unstored vs Stored calculations ... is it better in the long run if I try and avoid Unstored calcs at all costs and instead use the Evalute function in combination with a stored calc so that changes to the trigger fields will update the stored calc?

Thanks for your advice,

Toby

[Mikhail Edoshin]

I'd won't go this route, because sometimes you'll have to change data and logic parts and this cannot be done without importing old data. This means you need to have this functionality anyway. If you have separate layers, you'll need separate update procedures and though some of them may be simpler than importing, three is still more than one unified procedure.

Besides, you'll have to be rather cautious with what you store in the interface file you would like to merely replace. For example, you cannot store valuelists or accounts there, because if users edits a valuelist or alter accounts somehow, e.g. changes the password, these changes will be lost after the update.

[Toby B]

Thanks for the reply Mikhail,

From what I have seen from Wendy and Colleen I am not meant to have anything in the interface file except Layouts and Scripts.

However I am not using the value lists in this solution as I have opted to store these types of lists as tables in the data layer.

The reason I am looking into this "Separation Model" is because I now have to deploy my "under-development" single file solution to the second client (two companies sharing a studio space split the cost of development) as they want what the other has been using for a month or so now.

My ultimate goal here is to modularize the solution so that I can develop the remaining parts of solution whilst the clients are working on each of their slimmed down versions. I want to avoid having to do double the work (once for each of them).

I really want to send the new interface file to both of them (and obviously pointing each one to the corresponding data file) and simply get them to replace their old one.

I think I may need a second data file that holds my developer data that I never want the client to ever change or delete. This is another of my "ideals" ... try never to hard code something ... use a table instead.

Toby