| 

.NET C# Java Javascript Exception

3
Das Databinding in WPF ist ja sehr leistungsfähig und erlaubt z.B.

Content="{Binding Level2.Level3.Value}"

Jetzt stellt sich mir die Frage, wie das intern realisiert ist und welche Auswirkungen das auf die Performance hat.

Ich habe erst einmal einen Test gemacht, ob es wirklich funktioniert und das tut es:

Initialisierung:

this.level1 = new Level1() { Level2 = new Level2() { Level3 = new Level3() { Value = "Value1" } } };


Änderung auf:

this.level1.Level2 = new Level2() { Level3 = new Level3() { Value = "value2" } };


Der neue Wert wird in der UI korrekt angezeigt.

Das Framework muss dazu für das Binding für jedes Element im Pfad PropertyChanged registrieren, oder wie funktioniert das? Wie funktioniert es bei Collections, wo man über den Indexer zugreift?

Es scheint mir doch jedenfalls ein ganz schöner Overhead nötig zu sein.

Hintergrund ist eine Überlegung von mir View-Models zu modularisieren und verschiedene Aspekte wie Commands und Formatierungs-Properties zu trennen, da ich sehr große View-Models für ein absolutes Anti-Pattern halte.

Jedoch möchte ich mir auch über die Performance Gedanken machen.

Wenn ich richtig liege, würde der Speicherverbrauch für die Bindings mit jeder modularisierten View-Klasse steigen? Aber es sollte wohl noch OK sein im Verhältnis zu dem Speicher, was WPF eh schon alles frisst oder?
18.03.2013
kleffel 654 1 9
kleffel 654 1 9
2 Antworten
1
Aus eigener Erfahrung kann ich Dir sagen, dass man hinsichtlich Speicherverbrauch zwar gerne Vermutungen anstellt, aber es nicht tun sollte - die Realität straft einen in 98% der Fälle. Benutze einen Profiler (sei es VS integrierter Profiler, dottrace, ANTS, ... whatever) und führe eine ordentliche Messung durch. Optimiere gezielt und zerbrich Dir nicht den Kopf über mögliche Flaschenhälse. Sie sind meistens woanders, als man annimmt.

Zu WPF kann ich sagen, dass ich bereits einige komplexe Anwendungen damit realisiert habe und die mir zur Verfügung gestellte Funktionalität noch nie Ursache von (signifikanten) Performanceproblemen war.

Auch wenn ich nur entfernt erahnen kann, was Du erreichen willst, kann ich Dir aus meiner Erfahrung berichten, dass große ViewModels ein DesignSmell sind und sehr oft zu kleineren problemangepassten ViewModels refaktorisiert werden können. Auch wenn es von CQRS geklaut ist, ein Task-Based UI kann auch einer WPF Anwendung mit großen Data-Entities guttun. Nur so als Denkanstoss...
18.03.2013
ffordermaier 8,4k 3 9
Prinzipiell ist deine Antwort ja richtig, aber allgemein. Mich interessiert wirklich, wie das intern funktioniert. Ein bisschen Insider-Wissen hat noch nie geschadet.
kleffel 19.03.2013
0
1.) Schau Die einmal PRISM an. Hier handelt es sich um ein MVVM Framework, um Anwendungen zu entkoppeln und zu modularisieren. Grosse Views werden dabei in Regions unterteilt und entsprechend auch in kleiner ViewModels.
2.) Wenn Du Performance Probleme bekommst, dann in der Regel, weil
  • Deine Views selbst zu gross sind, (Stichwort: Visueller und logischer Baum),
  • Du zu große Liste verwendest (Stichwort: Virtualisierung) oder
  • Deine WCF/DB Zugriffe zu grosse Datenmengen transportieren (Stichwort: Lazy Loading).
WPF spezifische Analysen kannst Du mit der WPF Performance Suite überprüfen.
3.) Schau Dir mal das Law of Demeter an.
Level2.Level3.Value
ist ein NoGo.
18.03.2013
judgy 3,0k 1 1 8
Hast du mal die WPF Performance Suite schonmal unter Windows 8 zum Laufen bekommen?
kleffel 19.03.2013
Nein, habe ich noch nicht getestet.
WPF scheint unter Visual Studio 2012 ein wenig stiefmütterlich behandelt zu werden. Hatte Probleme den XAML Designer für WPF/Silverlight zum Laufen zu bringen.
Im Moment verwende ich Windows 8 nur zum Testen/Lernen/Spielen mit Windows Store - und WP8 Anwendungen.
Ansonsten verwende ich weiter Windows 7 und VS2010.
judgy 19.03.2013

Stelle deine .net-Frage jetzt!
TOP TECHNOLOGIES CONSULTING GmbH