または「Delphi で UI をビジネス ロジックから分離する方法は?」
各ターゲット プラットフォームには、固有の firemonkey コントロールの独自のセットがあります (Windows= VCL、MacOS= TMS mCL、Android= D.P.F、iOS=TMS iCLおよびD.P.F)。新しいFireUI(マルチデバイス フォーム デザイナー) は、スタイル付きコンポーネントには優れたソリューションですが、すべてのプラットフォームをサポートするにはマスター ペインに同じコンポーネントが必要なため、ネイティブ コンポーネントには適していません。それらを同じフォームに混在させることはできないため、Delphi のアイデア全体が完全に壊れてしまいます。
多くの開発者は、Delphiは壊れたアプローチであると言うでしょう。ただし、この質問の前提は、Delphiに反対することではなく、Delphi が提供するものから最良の結果を得ることです。
結論として、アプリケーションのフォームごとに、ターゲット プラットフォームごとに個別のフォームを作成する必要があります。これは、次の質問につながります。
課題 1 : ターゲット プラットフォームに応じてプロジェクトに異なるフォーム ファイルを含める方法は?
解決策 1 : MainForm_IOS.pas、MainForm_Android.pas、MainForm_Win、MainForm_OSX.pas などのすべてを含め、ファイル内でコンパイラ ディレクティブを使用して、ファイルの 1 つのコンテンツのみがアクティブになるようにします。欠点: 大規模なアプリケーションには多くのフォーム (約 40 あります) を含めることができるため、多数のインクルード ファイルについて話していることになります。
解決策 2 : それらをプロジェクトに含めずに、別のフォルダーに配置します。次に、一致するフォルダーを各ターゲット プラットフォームの検索パスに追加できます。欠点: プロジェクト マネージャーに表示されないため、ファイルを探す必要があるたびにワークフローが遅くなります。
解決策 3 : ターゲット プラットフォームごとにプロジェクトを作成します。欠点: 新しいユニットを追加したり、共通のプロジェクト設定を変更したりするたびに、それをすべてのプロジェクトに適用する必要があります (忘れずに)。
更新: Malcom Groves ビデオで提案されているように、すべてのビジネス ロジックをパッケージに配置すると、ソリューション 3 の欠点が取り除かれます。したがって、ソリューション 3 が最善のアプローチであると考えています。
課題 2 : 異なるデバイス フォームを (同じ) ビジネス ロジックに接続する方法は?
考えられる解決策: 通常はフォーム ユニットに含まれるすべてのコードを含む「ヘルパー」クラスを作成します。
更新: この「ヘルパー クラス」は、実際には MVVM が と呼んでいるものViewModelです。私が必要としているのは、データバインディングをサポートできる MVVM フレームワークのようです。私はそれについて別の質問をしました。
ベスト プラクティスに関する意見や提案を歓迎します。