Jeg bruger ofter ViewModel-first metoden når jeg anvender MVVM, dvs. jeg opretter først ViewModel instanser i koden og lader WPF om at finde de rette views for hver type af view model.

WPF har en DataTemplate som giver mulighed for at knytte views til mine view models:

<DataTemplate DataType="{x:Type vm:AlphaViewModel}">
  <view:AlphaView />
</DataTemplate> 

Lad os for eksemplet skyld antage at vi har en abstrakt GreekViewModel og et antal view models som nedarver fra denne, f.eks. AlphaViewModel, BetaViewModel, GammaViewModel, etc. Til hver view model har vi så et view, f.eks. AlphaView, BetaView, GammaView, etc. For hver view model anvender vi en DataTemplate for at knytte view model og view sammen. Lad os for ekspemplets skyld binde vores græske herligheder til en listbox.

<ListBox ItemsSource={Binding Greeks} />

Antallet af DataTemplates stiger hver gang vi tilføjer en ny view model, men for folk med god ordenssand (eller OCD) er der heldivis en nemmere måde at knytte view model og views sammen. 

Hvis man skeler til MVC kan man forstille sig at man kan udnytte en struktur som denne:

Hvis en view model, f.eks. AlphaViewModel, ligger i ViewModels folderen, så kan jeg forvente at et tilsvarende view, f.eks. AlphaView, findes i View folderen. For at få denne adfær kan vi benytte DataTemplateSelector. Det giver os mulighed for vælge en DataTemplate til hver view model i kode. 

public class GreekDataTemplateSelector : DataTemplateSelector
    {
        public override DataTemplate SelectTemplate(object item, DependencyObject container)
        {
            var viewModelTypeName = item.GetType().FullName;
            var viewTypeName = viewModelTypeName.Replace("ViewModel", "View");
            var viewType = Type.GetType(viewTypeName);
            var template = new DataTemplate();
            template.VisualTree = new FrameworkElementFactory(viewType);
            return template;
        }
    }

GreekDataTemplateSelector ser på typen af item (i vores tilfælde en instans af en view model) og gætter på et navn for typen af viewet. I eksemplet vælger vi blot at erstattet ViewModel med View, dermed bliver "ViewModels.AlphaViewModel" til "View.AlphaView". Klassen FrameworkElementFactory bruges til at knytte view typen til en DataTemplate. Eksemplet kan nemt udvides, f.eks. skal der sker noget hvis et view ikke findes. Man kan søge efter flere forskellige navne, eller at der vælges et default view. Under alle omstændigheder skal koden opdateres med fejlcheck inden du sætter den i produktion.

Vores ListBox skal også lige opdateres for at få den ønskede effekt:

 

<ListBox ItemsSource={Binding Greeks} ItemTemplateSelector="{StaticResource GreekViewSelector}" />

 

 

Husk lige at oprette en instance af GreekDataTemplateSelector i Resources. DataTemplateSelector kan benyttes på mange forskellige klasser og giver mulighed for at udnytte hvordan koden er fysisk struktureret. 

 

Benytter man HTTP stacken fra Silverlight – herunder kald af WCF services over HTTP – sker kaldet asynkront.  Derfor skal man passe på, hvis man opdaterer brugerkontroller i sin callback funktion, da den kan blive kaldt på en anden tråd end den, der ejer brugerkontrollen.  Det er gamle nyheder.  Bruger man et pattern som f.eks. MVVM, hvor opdatering af ens view sker gennem binding til properties på en viewmodel, sker marshalling til UI tråden automatisk af Silverlight’s binding mekanisme.  I andre tilfælde er man nødt til selv at sørge for, at brugerinterfacet opdateres på den rigtige tråd f.eks. gennem Dispatcher.

Jeg har først fornylig opdaget, at callbacks fra WCF services i nogle tilfælde automatisk bliver flyttet til den kaldende tråd i Silverlight.  Det gælder også Silverlight til WP7.  Det sker i det tilfælde, hvor man benytter client proxy klasserne, der genereres, når man vælger “Add service reference” fra Visual Studio. 

Lad os sige, at jeg har en service kaldet Service1 med en metode DoWork.  Jeg har tilføjet en reference til servicen gennem VS, hvorved et namespace ServiceReference1 med en proxy klasse kaldet Service1Client er blevet oprettet.  Følgende kode er dermed fuldt lovlig:

label1.Text = Thread.CurrentThread.ManagedThreadId.ToString();

ServiceReference1.Service1Client service = new ServiceReference1.Service1Client();
service.DoWorkCompleted += (s, args) =>
    {
        // Dette kald er fuldt lovligt, og label1 og label2 vil vise samme thread id.
        label2.Text = Thread.CurrentThread.ManagedThreadId.ToString();
    };
service.DoWorkAsync();

Kigger man dybt nok i de genererede klasser, kan man se, at de klassen AsyncOperation benyttes til at flytte kaldet tilbage til den kaldende tråd.  Har man brug for at lave noget arbejde i sin callback fra sin service, må man undlade at bruge den genererede client proxy og f.eks. bruge ChannelFactory eller noget andet.  Forrige eksempel er funktionelt ækvivalent med nedenstående, hvor marshalling til UI tråden sker manuelt gennem brug af AsyncOperation.  Bemærk at AsyncOperation skal oprettes gennem AsyncOperationManager.CreateOperation:

AsyncOperation asyncOp;

void CallWcf()
{
    asyncOp = AsyncOperationManager.CreateOperation(1);
    ServiceReference1.IService1Channel channel 
        = new ChannelFactory<ServiceReference1.IService1Channel>("BasicHttpBinding_IService1")
        .CreateChannel();
    channel.BeginDoWork(DoWorkCallback, channel);
}

void DoWorkCallback(IAsyncResult result)
{
    ServiceReference1.IService1Channel channel = result.AsyncState as ServiceReference1.IService1Channel;
    channel.EndDoWork(result);

    asyncOp.PostOperationCompleted(new SendOrPostCallback(o =>
        {
            label2.Text = (string) o;
        }), Thread.CurrentThread.ManagedThreadId.ToString());
}

I stedet for AsyncOperation kunne man også vælge at bruge SynchronizationContext eller Dispatcher direkte.  Faktisk er AsyncOperation blot en wrapper omkring SynchronizationContext, og i Silverlight er SynchronizationContext en instans af DispatcherSynchronizationContext, som igen er en wrapper omkring Dispatcher.  Så Dispatcher er den rigtige helt her.

Extension methods har vist sig yderst bekvemme.  Det mest kendte eksempel er naturligvis det væld af extension methods, man finder i LINQ.  De giver en mere præcis og kort notation.  Jeg synes dog, at det kan tage overhånd, fordi folk har tendens til at bruge extension methods til at “dekorere” typer med metoder, som egentlig ikke hører hjemme på typen.  Når frameworks som Rhino Mocks og testdelen af MVC Contrib bruger extension methods på strenge og andre ret grundlæggende typer, kan jeg acceptere det, fordi brugen af test frameworks er så præcist afgrænset.  Men når folk f.eks. begynder at putte extension methods for query string parsing og andet godt på alle strenge i et projekt, mener jeg, at man er gået over grænsen.  Man skal stadig følge OO-reglerne for godt design af en type.

Min egen brug af extension methods har derfor været yderst begrænset.  Jeg har dog defineret to meget nyttige extension methods til WPF typen DependencyObject: GetChild og GetParent.

Metoderne kan benyttes til rekursivt at vandre op eller ned i det visuelle træ for et DependencyObject.  De returnerer det første objekt, de støder på i træet, som er af den type, der er angivet som typeparameter til metoden. 

Koden ser ud som følger.  GetChild har jeg tyvstjålet fra et sted på nettet, hvor man kan finde et utal af nærmest identiske implementationer af metoden.

public static class VisualHelpers
{
    public static T GetChild<T>(this DependencyObject referenceVisual) where T : DependencyObject
    {
        DependencyObject child = null;
        for (int i = 0; i < VisualTreeHelper.GetChildrenCount(referenceVisual); i++)
        {
            child = VisualTreeHelper.GetChild(referenceVisual, i) as DependencyObject;
            if (child != null && child is T)
            {
                break;
            }

            child = GetChild<T>(child);
            if (child != null && child is T)
            {
                break;
            }
        }
        return child as T;
    }

    public static T GetParent<T>(this DependencyObject referenceVisual) where T : DependencyObject
    {
        if (referenceVisual == null)
            return null;
        if (referenceVisual is T)
            return referenceVisual as T;
        var parent = VisualTreeHelper.GetParent(referenceVisual);
        return parent.GetParent<T>();
    }
}

Så hvad kan man bruge metoderne til?  F.eks. kan man bruge GetChild til at style textbox-delen af en combobox.  Det er der nemlig ikke mulighed for “out-of-the-box”.  Det kan gøres ved at nedarve fra ComboBox og lave en override af OnApplyTemplate.  I OnApplyTemplate benyttes GetChild til at finde combobox’ens ContentPresenter og ændre dens ContentTemplate:

public class ComboBoxEx : ComboBox
{
    public override void OnApplyTemplate()
    {
        base.OnApplyTemplate();
        var selectionBoxHost = GetChild<ContentPresenter>(this);
        if (selectionBoxHost != null)
        {
            selectionBoxHost.ContentTemplate = ...;
        }
    }

}

I WPF benyttes INotifyPropertyChanged hyppigt ifm. binding af view model til view.  De fleste er nok stødt på en variant af følgende standardimplementation:

public event PropertyChangedEventHandler PropertyChanged;

protected virtual void OnPropertyChanged(string propertyName)
{
    PropertyChangedEventHandler handler = this.PropertyChanged;
    if (handler != null)
    {
        var e = new PropertyChangedEventArgs(propertyName);
        handler(this, e);
    }
}

I ens view model kaldes OnPropertyChanged i get’eren i de properties, der indgår i binding til view:

public string SomeProperty
{
    get { return _someProperty; }
    set
    {
        if (_someProperty != value)
        {
            _someProperty = value;
            OnPropertyChanged("SomeProperty");
        }
    }
}
 

Det er naturligvis vigtigt, at parameteren til OnPropertyChanged er det samme som navnet på ens property.  Jeg ved ikke, hvor mange gange, jeg har glemt at opdatere det navn, når jeg har ændret navn på min property.  Man opdager hurtigt fejlen, men hvor det dog irriterende.  Så jeg har lavet en alternativ og meget simpel version af OnPropertyChanged, som benytter expression trees.  Den ser således ud:

protected virtual void OnPropertyChanged<T>(Expression<Func<T>> e)
{
    var member = (MemberExpression) e.Body;
    OnPropertyChanged(member.Member.Name);
}

 

Den nye overload kaldes med en lambda:

OnPropertyChanged(() => SomeProperty);

Hvis jeg fremover ændrer navnet på min property, vil VS2008 automatisk opdatere i min lambda.  Lamdaudtrykket skal have den form, som er vist ovenfor, ellers får man en exception.

Desværre løser det ikke alle problemer med renames, da jeg stadigvæk selv skal huske at opdatere i XAML-filen.