Business Logic File?

[raymanj]

Have been reading about FM7's ability to separate data from interface. I have been looking over the FileMaker tech brief doc "techbrief_fm7_foundations.pdf". In there I found a section regarding the interface and data file separation. They not only talk about these two file layers (data and interface)but a third (business logic),

They say that the business logic layer file should contain derived-data fields, summary fields, value list that change, reports, etc. Its benefits are for quick re-purposing the file for other solutions.

A few examples they gave:

Invoice line item file has the data fields - product ID, quantity, price.

While the business logic file would hold the extended price field, since it is considered a derived data field.

Contact Name file data fields - first name and last name

Business logic file would hold certain calc fileds that would display Last, First name or Mr/Mrs. Last name.

This sounds great but they forgot to show how to set this up in filemaker. My only thought, to get this working, was to create a separate record, in the business logic file, for every data record in the data file. Then link them with some relationship. It works but I don't see the benefits they were talking about.

How does this save me time, when I could create those same fields in the data files. If I needed to change the calcs and re import all the data to the new files, wouldn't I need to do the same with the business logic file setup. I would have a business logic record count equal to all my data record counts.

If anyone has read this tech brief or have been working on data interface separations for their solutions could you explain to me if the above explaination is right or wrong with the business logic layer file.

Thanks

[RalphL]

It easy to recreate the records you need in the Business Logic file. You don't have to import any data into them. Use a one to one relationship between the data tables and the business logic tables. For some reports I found that I only need a single record.

It does take a little more effort to set it up but updating should be a snap. I have more tables now but only 3 files.

[DanBrill]

raymanj said:

If I needed to change the calcs and re import all the data to the new files, wouldn't I need to do the same with the business logic file setup.

Thanks

No, you'd only need to create the corresponding records in the business logic file. There'd be nothing to import because the calcs are operating on the data in the data files. They have no data native to themselves.

Having said that, I'm still dubious that this really makes sense. Ralph and I had a long discussion about this in another thread (which I can't seem to find on the forum at the moment). Ralph gave some great direction, but I don't think I'm convinced of the while concept.

First, if you are creating a solution to be used on one site and one site only, then it makes no sense. Create one file and be done with it. Update as you like.

If you are creating a distributed solution, then it makes a great deal of sense to seperate your solution into at least 2 files: scripts and layouts (and probably some globals), and another file with data and calcs.

You can go the extra step and create 3 files -- data, scripts and layouts, and the business logic file with the necessary calculations. However, this will cause extra scripting to keep the data file 'in sync' with the business logic file; that is, making sure that each record has a corresponding record that it can be related to in order to make the calculations calculate.

In a program like Access with a query that is seperate from the data table, the query (where the calculations are built) always has as many records as the table upon which it is based. This isn't the case with FileMaker. There is no way to make one table automatically have the same number of records as another. This has to be done with scripting. Every new record and deleted record and imported record in the data file will have to be mirrored in the logic file. It just seems to me that there are ways for this to go wrong, and it slows it all down, and makes it more difficult to design layouts and reports since you'll have to be drawing raw data from one file and calculated data based on the raw data from another.

In the end, this seems more complex than having a combined data and logic file. If you need to update it, then just script the imports. (Besides, if I want to add one more field for raw data in the data file I'll need to have the scripted imports ready anyway, so this is no big deal. And this will come up as some user will have a need for some piece of data you'd never thought of before.)

So I vote for a script/layout file and a data/calc file if you are distributing a solution.

But I could be wrong.

Cheers,

Dan

[raymanj]

It seems the only real benefit to the business logic layer is fro re purposing your solution. If you are not re purposing it then you don't need the business layer.

It would be nice if someone could post some example files that incorporates business layer file.

thanks

[raymanj]

Here is a sample business logic file that I created. It is linked with an interface and data file. It is very rough but is what I envision this type of file to be based on the tech brief doc.

Any pointers, corrections or additions are welcomed.

I would like to created an extensive discussion about this new method of FM solutions.

School.zip