FMシステム設計の考え方

Google で「FileMaker 分離モデル」や「FileMaker D.R.Y(Don't Repeat Yourself)」で検索するといろいろ見えてくるものもあるでしょう。

手法として多いのは、データファイルのテーブルを外部データソースに指定して、インターフェイス側のファイルにテーブルオカレンスを置いてスクリプトやレイアウトを一つのファイルで完結できるように 努力する かんじでしょうか。

カスタム関数はファイルを横断できませんから各ファイルにコピーして使う形になりますし、ユーザには権限のない動作をスクリプトでは実行させたい場合は、データ側のファイルの完全アクセス権で実行のチェックの入ったスクリプトを実行させることになるので、データ側のファイルにもスクリプトが必要になってきたりしますので、インターフェイス側だけで完結するのは難しかったりもします。

また、単機能の（例えば住所を正規化するようなものとか）ファイルをモジュールのように呼び出して使いまわしすることもしますが、複雑でないものだったら、必要なスクリプトやテーブルをコピペして使った方が楽だったりもします。

FileMaker : 録画Webセミナー  の「効率的なFileMakerソリューション開発の実践テクニック - どこでも使えるスクリプト」や Modular FileMaker が参考になるかと思います。

ファイルを別にした「共通のプログラム（スクリプト・ユーザ関数）」はFileMakerでは限られてくるかなと。

例えば、[レイアウト切り替え]スクリプトステップはそのファイルにないとダメ。

なので、「共通のプログラム」に出来ない。他にも「関連レコードへ移動」「新規ウインドウを開く」辺りですかね。

では何が共通のプログラムになるかというと、郵便番号簿で郵便番号を引数に入れると住所が返ってくるとか、その逆とか。でも、それって「共通のプログラム」というよりはモジュール化した機能ですよね。

複雑な計算とかなら共通に出来るかな。いくつか引数与えると結果を返すような。

また、データを料理するにしても、前述の様に引数与えて戻り値を取得するか、その「共通のプログラム」が実行されるレイアウトに料理したいテーブルオカレンスが必要となってきます。

結局、データとセットになってしまう場合が多いので「共通のプログラム」って難しいかなと。

無理してやっても保守利便性が下がってしまうので、機能単位でファイル分けた方が、ファイル間の依存性が下がるので複数人数で開発もし易いですし、システムのアップデートするときも楽かなと。

もちろん設計がバラバラになるのは保守性が落ちるので、統一しておいた方がいいと思います。

そして、スクリプトをコピペ。