xaml - FsXaml 类型提供程序相对于 XamlReader 的优势

Question

F# 不支持部分类，也不支持 XAML 文件的预编译。解决方法:在运行时加载图形对象定义，而不是后面的编译时代码。有多种方法可以为 XamlReader 提供引用资源文件的内容。

open System.Windows

// from Resource
let uri = System.Uri "pack://application:,,,/AssemblyName;component/MainWindow.xaml"
let info = Application.GetResourceStream uri
let wnd = Markup.XamlReader.Load info.Stream :?> Window

// from Embedded resource
let assembly = System.Reflection.Assembly.GetExecutingAssembly()
let stream = assembly.GetManifestResourceStream "MainWindow.xaml"
let wnd  = Markup.XamlReader.Load stream :?> Window

类型提供者应该能够至少将部分工作转移回编译时。

open FsXaml
type MainWindow = XAML<"MainWindow.xaml"> 
let mainwnd = new MainWindow()
let wnd = mainwnd.Root

类型安全(和发现)方面的 yield 似乎微不足道:一种运行时类型对每个资源的转换较少。还有其他优势吗？

Answer 1

The gain in type safety (and discovery) seems to be marginal: one runtime type cast less per resource.

这里还有其他优点，即使在您显示的代码中也是如此。在您的示例中使用 FsXaml 更加简洁，并且完全类型安全。如果您的 XAML 文件中存在重大问题，它也会在编译时失败，使用 XAML 加载器将其推迟到运行时。

Are there other advantages?

有很多优点——

较短的代码

类型安全

以类型安全的方式作为属性公开的命名元素

(最重要)创建与您的 XAML 类型相对应的实际类型

最后一点确实是 FsXaml 与 XamlReader 的“杀手级”优势——没有这一点，除了 WPF 中的“玩具”项目之外，几乎不可能做任何事情。如果您希望能够嵌入 XAML，您需要有与您的类型相对应的“真实类型”。

例如，如果要使用作为数据模板开发的 UserControl，则需要该 UserControl 是实际类型，而不仅仅是某种 XAML 作为资源。使用 XamlReader，无法从其他 XAML 引用它。您也不能重用资源、将数据拉入您的应用程序或许多其他事情(无需在运行时通过手写大量管道来完成)。

此外，使用 FsXaml 2+，您可以子类化类型并在“代码隐藏”中提供完整逻辑，这与您在 C# 中的工作方式类似(尽管不同)。

这使 Xaml 更接近于在 C# 中工作时的体验 - 仍然没有 BAML 编译(一个缺点)，但除此之外，当使用 F# 和 WPF 工作时，您将获得与 C# 相当的体验。