WPF - databinding… the good, the bad and the really ugly
Som udgangspunkt kan stort set alt i WPF databindes på kryds og tværs. Det eneste, der kræves er en datakilde og en dependency property. Datakilden er det man i videst mulige omfang kan komme i nærheden af at betegnes som en datakilde. Alt kan anvendes, hvis det giver bare den mindste mening i forhold til property’en.
Ved hjælp af IValueConverters kan alt lægges til grund som datakilde - en property der accepterer doubles, kan via en avanceret omregningsformel blive styret af rumfanget af tre meta-tags på et billede osv. Det er derfor i høj grad kun op til udviklerens opfindsomhed at finde på nye og spændende måde at lave afhængigheder på. Man bør i alle tilfælde overveje om det nu også i alle tilfælde er smart at applikationens design og data afhænger af farven på processorens venstre ventrikelkernes temperatur… sagt på en anden måde - bare fordi man kan, er det ikke ensbetydende med at man skal!
I vores applikation, som er meget datatung, har vi prøvet at begrænse os til at anvende enkelte teknologier og fremgangsmåder, og så tilgengæld anvende dem fornuftigt. Vi anvender så vidt muligt ikke IValueConverters. Når vi databinder anvender vi i videst muligt omfang ObjectDataProviders og implementerer INotifyPropertyChanged (via CSLA) på alle objekter. Det gør det muligt run-time at udskifte objekterne uden at skulle ændre i databindingen. Vi bruger meget templates og styles til at vise objekter på en fornuftig og ensartet måde.
Vi prøver så vidt muligt at lave visuelle objekter så generiske som overhovedet muligt. Som eksempel kan det nævnes at vi har en (1) usercontrol til at oprette 10 forskellige stamdata objekter. Der er ikke en hardkodet business type i den. Det har givet os nogle … udfordringer i brugen af XAML. XAML er ekstremt godt til at lave ’statiske’ skærmbilleder med kendte (på design-tidspunktet) typer og mindre godt til generiske typer. XAML har desværre vist sig at være for ‘knudret’ til virkelig at finde sin hædersplads i vores arsenal af værktøjer.
Databinding er - efter at vi har tillært os nogle færdigheder - ved at være helt på plads. Det største problem har været at finde ud af hvorfor, når det ikke virker. Debugging mulighederne for bindingen er, for at sige det mildt, utilstrækkelige. Når displayet ikke virker, kan det være noget så banalt som en stavefejl i properties over et problem med at datacontexten på et givet tidspunkt ikke er tilgængelig (er null) til problemer med propertien på objektet ikke var stavet ligesom på dependency-property’en… og der er ikke nogen hints at finde… DataBindingen fejler ‘lydløst’ - sikkert fordi det er så løst koblet som det er. Når datasourcen bliver sat, bliver det ikke checket om en given property findes på objektet - derimod bliver det checket om den property passer sammen med det valgte BindingMode. Default BindingMode er desuden forskellig alt efter hvilken kontrol man har fat i - og de properties man skal binde til, hedder noget vidt forskelligt - og man kan opnå samme resultat med mange forskellige properties.
Alt i alt, er vi meget glade for at have fundet en fast metodik til hvordan _vi_ laver databinding. I mange tilfælde vil en anden tilgang højst sandsynligt være mere effektiv på et givent objekt, men det ville være på bekostning af gennemskueligheden af koden.
Jeg glæder mig til at der bliver udviklet et gennemtestet pattern med databinding i forskellige situationer.