4 返信 最新の回答 日時: Feb 5, 2015 8:50 PM ユーザー:fumitopapa

    FMシステム設計の考え方

    fumitopapa

      おせわになっております。

      FMの可用性どこまで可能か不明なところがあります。みなさんの知恵を頂きたいです。

       

      前提はレイアウト(プログラム)部 と DBは別々でのこと。もちろんFM限定の話です。

      プログラムは機能単位で分けたい(物理上ファイル別)、保守利便性のため。

       

      質問 上記の前提で、共通のプログラム(スクリプト・ユーザ関数)などどのように配置するよいでしょうか?

      Javaの例なら、フレームワークにすることで、物理的別々のファイル、そちから呼び出すことで、各プログラム間行き渡りのような構造。

       

      よろしくお願いします。

        • 1. Re: FMシステム設計の考え方
          user14047

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

           

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

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

           

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

           

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

          • 2. Re: FMシステム設計の考え方
            sago350@未来Switch

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

             

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

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

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

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

             

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

             

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

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

             

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

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

            • 3. Re: FMシステム設計の考え方
              fumitopapa

              迅速のご回答、ありがとうございます。

              やはり、製品の構造上に制約があるようですね、以前VBで開発するとき、各画面は1つ実行ファイル、DBへのアクセス、システム共通のものは一カ所に集まって、クラスモジュールする手法は一般的、FMの特徴から開発簡潔することで、大規模・分散など難点もあることもよくわかりました。アドバイスを頂いたうえで今後活用させていただきます。

              • 4. Re: FMシステム設計の考え方
                fumitopapa

                sagoさん

                 ありがとうございます。大変参考になります。FMの開発は少人数前提で、ひとつのプログラムのカタマリ作成する体制は念頭に置くことで活用致します。