或"如何在Delphi中将UI与业务逻辑分离？"
每个目标平台都有自己的一组原生 firemonkey 控件(Windows= VCL、MacOS = TMS mCL、Android= D.P.F、iOS= TMS iCL 和 D.P.F(。新的FireUI(多设备窗体设计器(是样式化组件的绝佳解决方案，但不适用于本机组件，因为它仍然需要母版窗格上的相同组件来支持所有平台。由于您无法在同一形式上混合它们，因此完全打破了Delphi的整个想法。
很多开发人员会说Delphi是破碎的方法，请参阅"为什么FireMonkey在各个方面都如此根本错误"。然而，这个问题的前提不是反对德尔福，而是从它提供的东西中获得最佳结果。
结论是，对于应用程序中的每个表单，您必须为每个目标平台创建一个单独的表单。这会导致以下问题：
挑战 1：如何根据目标平台在项目中包含不同的表单文件？
解决方案1：包括所有这些，即MainForm_IOS.pas，MainForm_Android.pas，MainForm_Win，MainForm_OSX.pas，然后在文件中使用编译器指令，因此只有一个文件的内容处于活动状态。缺点：一个大型应用程序可以有很多形式(我们有大约 40 个(，所以我们谈论的是大量包含的文件。
解决方案 2：不要将它们包含在项目中，而只是将它们放在单独的文件夹中。然后，可以将匹配的文件夹添加到每个目标平台的搜索路径中。缺点：它们不会显示在项目管理器中，因此每次需要查找文件时都会减慢工作流程。
解决方案 3：为每个目标平台创建一个项目。缺点：每次添加新单元或更改常见项目设置时，都必须(记住(将其应用于所有项目。
更新：如 Malcom Groves 视频中所建议的，将所有业务逻辑放在一个包中将消除解决方案 3 的缺点。因此，我认为解决方案3是最佳方法。
挑战 2：如何将不同的设备表单连接到(相同的(业务逻辑？
可能的解决方案：创建一个"帮助程序"类，其中包含表单单元中通常包含的所有代码。
更新：这个"帮助类"实际上是MVVM所说的ViewModel。我需要的似乎是一个可以支持数据绑定的 MVVM 框架。我对此提出了另一个问题。
欢迎任何有关最佳实践的意见和建议。
对于挑战 1：您可以根据编译目标有条件地链接 FireMonkey 表单资源：
{$R *.Windows.fmx MSWINDOWS}
{$R *.Macintosh.fmx _MACOS}
等。
这正是 XE7 Multiview 设计器所做的，但我不反对使用此机制有条件地将整个表单文件链接到可执行文件。当然，您可能还想在项目文件中ifdef相应的单位。
对于挑战 2：只需使用某种形式的模型视图控制器逻辑。因此，您的平台依赖表单将与平台独立控制器通信。