Vorteil des Providers FsXaml über XamlReader

Question

F # unterstützt weder partielle Klassen noch die Vorkompilierung von XAML-Dateien. Die Problemumgehung: Laden Sie die grafischen Objektdefinitionen zur Laufzeit statt des Codes für die Kompilierungszeit. Es gibt verschiedene Möglichkeiten, XamlReader mit dem Inhalt einer referenzierten Ressourcendatei zu versorgen.

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 

Typ-Anbieter sollten in der Lage sein, zumindest einen Teil dieser Bemühungen zu verschieben zurück zu Zeit zu kompilieren.

Der Gewinn in der Typsicherheit (und Entdeckung) scheint marginal zu sein: Ein Laufzeittyp wird weniger pro Ressource gewirkt. Gibt es andere Vorteile?

Answer 1

Der Gewinn in der Typsicherheit (und Entdeckung) scheint marginal zu sein: Ein Laufzeittyp gibt weniger pro Ressource aus.

Es gibt andere Vorteile, auch in dem von Ihnen angezeigten Code. Die Verwendung von FsXaml ist in Ihrem Beispiel viel prägnanter und vollständig typsicher. Es wird auch zur Kompilierzeit fehlschlagen, wenn es große Probleme in Ihren XAML-Dateien gibt, wo die Verwendung von XAML Loader dies zur Laufzeit verzögert.

Gibt es noch weitere Vorteile?

Es gibt viele Vorteile -

• Shorter Code
• Typ Sicherheit
• Benannte Elemente als Eigenschaften in einer Art sichere Weise ausgesetzt
• (Wichtigster) Erstellt tatsächlichen Typen entsprechen Ihrer XAML-Typen

Der letzte Punkt ist echt ly der "Killer" Vorteil von FsXaml vs XamlReader - ohne dies ist es fast unmöglich, etwas über "Spielzeug" -Projekte in WPF hinaus zu tun. Sie müssen "echte Typen" haben, die Ihren Typen entsprechen, wenn Sie XAML einbetten möchten.

Wenn Sie beispielsweise Benutzersteuerelemente verwenden möchten, die Sie als Datenvorlagen entwickeln, benötigen Sie dieses Benutzersteuerelement als tatsächlichen Typ, nicht nur ein XAML als Ressource. Mit XamlReader gibt es keine Möglichkeit, das von anderen XAML zu referenzieren. Sie können auch keine Ressourcen wiederverwenden, Daten in Ihre Anwendung ziehen oder viele andere Dinge (ohne dafür zu sorgen, dass während der Laufzeit eine große Menge an Rohrleitungen von Hand geschrieben wird).

Darüber hinaus können Sie mit FsXaml 2+ Typen ableiten und vollständige Logik innerhalb des "Codes hinter" bereitstellen, ähnlich (wenn auch anders) von Ihrer Arbeitsweise in C#.

Dies bringt Xaml viel, viel näher an die Erfahrung bei der Arbeit in C# - Es gibt immer noch keine BAML-Compilation (der einzige Nachteil), aber sonst erhalten Sie eine Erfahrung, die effektiv mit C# bei der Arbeit von F # mit WPF.

Answer 2

Ein Typ Provider überprüft Dinge zur Kompilierzeit, der Xaml-Reader arbeitet zur Laufzeit.
So werden Fehler entweder beim Kompilieren oder zur Laufzeit erkannt. Es ist ziemlich offensichtlich, dass das Auffinden von Fehlern früher im Entwicklungsprozess besser ist.