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