MVVM == Model View ViewModel Pattern is a MUST follow pattern in Silverlight (WPF). here is why…

Problems it solves:

•Tight coupling of layers (ex a query in the UI)

•Unit testing is hard/impossible, only functional testing is possible

•Assures codes still works correct after a change

•ViewModel

•Provides View with data model and behavior

•View will bind to ViewModel

•Wraps data access entirely

In light of new technologies like RIA services (which provides CRUD) operations out of the box it is imperative that users are tempted to overlook MVVM for sake of simplicity!!! However, the goodies MVVM brings along holds good in RIA services well… So what the roadmap to have MVVM , silverlight and RIA services???? I havnt found much on google (& BING!!!) but here is my humble take on that.

I plan to write more in my forthcoming blog but here is one example using nInject.

nInject is lightweight DI framework and is helpful in injecting VIEWMODEL right into XAML code!!! here is how…

   1: Title="Home"

   2:   DataContext="{Binding Path=HomeViewModel, Source={StaticResource serviceLocator}}"

   3:   Style="{StaticResource PageStyle}">

Notice … the datacontext (VIEW MODEL) is injected using ServiceLocator!! the service locater is itself a resource defined in APP.xaml

   1: Application   

   2:   x:Class="SilverlightApp.App"

   3:   xmlns:local="clr-namespace:SilverlightApp.ViewModel"

   4:   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

   5:   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

   6:  

   7:   <Application.Resources>

   8:   

   9:     <ResourceDictionary>

  10:       <ResourceDictionary.MergedDictionaries>

  11:         <ResourceDictionary Source="Assets/Styles.xaml"/>

  12:       </ResourceDictionary.MergedDictionaries>

  13:     </ResourceDictionary>

  14:         <local:ServiceLocator x:Key="serviceLocator" />

  15:     </Application.Resources>

  16:  

  17: </Application>

and Ninject code for Service Locater goes like…

   1: namespace SilverlightApp.ViewModel

   2: {

   3:     using Ninject.Core;

   4:     public class ServiceLocator

   5:     {

   6:         private static readonly IKernel kernel;

   7:  

   8:         static ServiceLocator()

   9:         {

  10:             if (kernel == null)

  11:             {

  12:                 kernel = new StandardKernel(new Module());

  13:             }

  14:         }

  15:  

  16:         public HomeViewModel HomeViewModel

  17:         {

  18:             get

  19:             {

  20:                 return kernel.Get<HomeViewModel>(); 

  21:             }

  22:         }

  23:  

  24:         public static T Get<T>()

  25:         {

  26:             return kernel.Get<T>();

  27:         }

  28:     }

  29: }

The commands are taken care by the SLExtensions. here is how…

I will be using and blogging about the following DI … Please feel free to write more… if you have anything to add..

1. Nikhil Silverlight FX… This is really good stuff; the only thing which is “does NOT” goes down well (to most of developers) is use of customized controls. Having said that i must say, personally, i love this approach and how Nikhil keep updating it with newest stuff!!!

2. CAB(Prism): I personally think it is more opt for WPF. Having said that it also follows “injection through interface” paradigm.. which sometimes introduces too much hassles…

3. MEF. Latest from Microsoft. Very promising, however yet to mature as a tool.

4. Caliburn: Excellent tool. I found it at codeplex…

My plan is to retest each of the above wrt SL3.0, RIA services abd MVVM in context abd post results on this blog.. and get more tractions on the results i get to..

Keep jotting your comments…

J’ai eu le temps dans le train de réfléchir à quelques problèmes qui s’annoncent dans l’évolution à venir de Swinger. Jusqu’à présent, j’ai laissé de côté les composants complexes de Swing tels que les JTree ou encore les JTable. La raison est que cela nécessite de pouvoir spécifier des valeurs à insérer dans le model comme dans le cas des tables en HTML. J’avais commencé à introduire une balise <item> qui était utilisée pour les JList, mais je suis finalement revenu en arrière car l’approche n’était pas la bonne. Les items ne font pas partie de la couche Vue mais de la couche Model. Il n’était donc pas judicieux de traiter communément ces deux types d’élément.

La solution que j’adopterai du point de vue du langage sera l’introduction des namespaces. Ils permettront d’identifier les différentes couches de l’api Swing. Du point de vue de l’implémentation, je suis toujours confronté à la nécessité de différencier les traitements associés à ces couches. Pour cela, j’adopterai une implémentation simplifiée du pattern Inversion of Control.

Prenons comme hypothèse de départ que vous êtes en présence d’une architecture dans laquelle l’implémentation d’une responsabilité varie selon le type de composant passé en paramètre.

Plutôt que d’implémenter la responsabilité dans une seule méthode avec des vérifications de casting, je dispatch la responsabilité dans des méthodes différentes selon le type d’objet à traiter, et je délègue l’appel de la méthode idoine au niveau des composants subalternes.

Typiquement, l’implémentation sera celle-ci :

public class Child1 implements IoC {
    @Override
    public void delegate(Parent parent) {
        parent.method1();
    }
}

public class Child2 implements IoC {
    @Override
    public void delegate(Parent parent) {
        parent.method2();
    }
}

Cette approche me permettra de conserver le caractère modulaire de Swinger. Tout type de composant pourra être ajouté à un parent, ça sera le composant fils qui déterminera de quel manière il sera ajouté à son parent. Actuellement, seule la méthode Container.add() est utilisée. Avec cette nouvelle architecture, il sera même possible d’ajouter un layout à un conteneur grâce à une balise. Je rappelle que c’est ce problème qui m’avait amené à l’origine à implémenter CSS. Je n’ai pas pour autant l’intention d’abandonner CSS car je pense que cela apportera une plus grande simplicité dans la création d’IHM.

using System;public interface FlyBehavior{void Fly();}

public class FlyWithWings : FlyBehavior{public void Fly(){Console.WriteLine(“I can fly cause i have wings to fly”);}}public class FlyNoWay : FlyBehavior

{#region FlyBehavior Memberspublic void Fly(){Console.WriteLine(“I can’t fly cause i have no wings”);}#endregion

{public FlyBehavior flyB;public Duck(){}public abstract void Display(); public void performFly(){flyB.Fly();}

public void setFlyBehavior(FlyBehavior fb){flyB=fb;}

public class DonaldDuck :Duck {public DonaldDuck(){flyB=new FlyWithWings();}public override void Display(){

Console.WriteLine(” I am a real Donald Duck”);}}public class DuckSimulator{

public static void Main(){Duck dd=new DonaldDuck();dd.performFly();// donald duck can’t fly now dd.setFlyBehavior(new FlyNoWay() );dd.performFly();}}

Mike Feathers has posted an article in which he defends the use of null parameters, but only under certain circumstances: He likes them as parameters to constructors when building lightweight objects in tests.

As you know by now, dear reader, I have railed long and loud against the use of null parameters. And so I find myself disagreeing with Mike on this topic. [Mike, I would have commented directly on your blog, but why do I need an Artima account to do so?]

Mike suggests that it is always worth trying a line such as

ADBDocument doc = new ADBDocument(null, 0, null);

when writing a test. If it works, he says, you get a lightweight object that can be just good enough to write the test and continue. But is the code now truly intention-revealing? If it were indeed sensible or feasible to create a ADBDocument with no inputs to the constructor, perhaps a zero-argument constructor should have been provided; or a factory method called newUnprintableDocument()? It seems to me that there is now a brittle relationship between the test method and the implementation of at least one constructor for the ADBDocument class, and that makes me nervous.

You are tempted to create a method with a boolean argument. The caller will set the argument to true or false depending on which code path he wishes the called method to take. This is an extremely convenient way to add a small degree of configurability to an algorithm, and means that both paths through the called method can share setup and cleanup code.

class MyClass

    void dosomething(boolean followPathA) {
        // setup
        if (followPathA)
            // pathA
        else
            // pathB
        // cleanup
    }

However, the use of a boolean argument reduces readability. For example, in a method such as
workspace.createFile(name, true), what does “false” mean? It is much more intention-revealing to call a method such as workspace.createTempFile(name). Furthermore, boolean arguments always create duplication, either of code or of responsibility, and often of a very insidious nature. This is because the called method contains a runtime test to decide between two different code paths, despite thet fact that the calling method already knows which branch it requires! The duplication not only wastes a little runtime, it also spreads knowledge and responsibility further than is necessary. The resulting code is more closely coupled than the design it represents. These effects are magnified exponentially each time the boolean argument is passed on in a further method call.

Therefore avoid the need for a boolean argument by creating two versions of the method, in which the meaning of the boolean is reflected in the names of the new methods. For example, replace

File createFile(String name, boolean istemp)

by

File createFile(String name)
File createTempFile(String name)

If the resulting new methods have similar logic, extract the duplicate code into shared methods that can be called by each.

(Here’s a fun story on a related theme.)