Code included here is over simplified for clarity, I hosted a better implementation code on CodePlex. These modifications change strictly nothing for the client code and are only an implementation detail. I use a continuation rather than a delay, and I chose to design a custom continuation class rather than using a delegate because of a type system limitations.

Most GUI frameworks, including Silverlight and WPF, are shipped with a fundamental problem: long use of the main thread causes the Window to blackout, and using different threads requires you to get your hands dirty with the Dispatcher stuff and freezable objects. Worse, you wont learn the necessity to do so until you get a surprise of “The calling thread cannot access this object because a different thread owns it.” exception when all what you were doing is to use available methods on an object that seemed you have access to, at lease it seemed until runtime! This post illustrates a solution based on Monads abstraction and LinQ syntax.

This is a problem you get often when applying Model View Presenter pattern [MVP]. There, your view (which is a WPF control) implements a contract IView that the presenter in its turn will use to extract values and then make operations on the view.

interface ISayHello { string GetName(); Unit SayHello(string name); }

class MyLoginControl:Control,ISayHello {

//this interface gets implemented by the corresponding control as texboxes and a text area…

}

The problem appears when for doing any realistic responsive application, the presenter (representing business operations if you’d like) will have to run on a background thread to leave the main thread free for graphics rendering.

While working on a background thread, the presenter needs to access the view (having a reference to it through a contract) and there something wrong happen “The calling thread cannot access this object because a different thread owns it.” . 

The problem here is simply that the view is giving quite a promise that it simply can not satisfy which is implementing the IView contract.

The view cannot satisfy the ISayHello contract under all circumstances, and not even under a commonly desirable condition (the presenter or business code running on another thread). This fact is simply not communicated through the type.

The solution I suggest to this problem that I implemented and employed in a production real world project is based on the LinQ syntax added to C# last year. In the solution I use two things: an extension method and a special type.

The type that I use is the monadic type (thanks to Wesdyer for his enlightening posts): View<T>

So in my case my type will be View<IView> which means that what I am offering here is a a type that acts under some special circumstances as the Contract ISayHello . If I want for example to extract the name from the WPF control, I need to do something with the View<ISayHello>. 

Using the View<T> Monad:

And here comes the LinQ syntax for help. Having a reference to View<ISayHello>, the only way with which I can access the desired value or methods is using Linq:

Having the view contract:

I can extract a view monad that I can pass to the presenter as View<ISayHello> 

note the type View<ISayHello> which is somehow useless without the LinQ syntax:

and you can also use several contracts in the same expression:

Implementation of the View<T> Monad:

View<T> is not really special. It is just a Delay<T> which is a Func<T>. And the Select implementation is the same one for functions and is not special at all:

The fact that I am defining a new delegate type here (View<T>) is because we don’t have type synonyms is C#. And because of this I had to reimplement all the Select methods for this type. Of course all of that Monad plumping code is invisible and all the user needs to do is use the LinQ syntax.

The only specific part about the View monad, is the way you extract it. For Wpf for example the .AsView implementation looks like:

Which merely tells about how to execute the delay when applied.

This is the code responsible for calling on WPF windows using dispatcher and other plumping details. Again code here is simplified for clarity. In the same way one can implement an AsView extension method for Silverlight with no need to change the Select implementation. View<T> is a generic monad and contain nothing specific to GUI technology.

Conclusion

The Monad generalization provides a good solution for WPF/Silverlight thread problem. The solution is barely about communicating through the type system the fact that WPF/Silverlight controls are special, and using LinQ expression to operate on them leaving the plumping (Dispatcher.Invoke, Freezable) to the monad library implementers. Also this frees the caller from thread logic that is specific to the implementation technology.

In my project I didn’t work much on the freezing/unfreezing of Wpf controls (copy them and extract them to other threads) as it actually wasn’t necessary for my project. However, I think that a proper implementation of .AsView for WPF/Silverlight that manages Freezable and nested Freezable objects copying would be very interesting and would complete the API.

PS: I decided to finish this draft quickly as I am not having enough time to finish properly. Please tolerate typos and don’t hesitate to ask questions.

 www.codeplex.com/nmvp

Ces lignes vont vous montrer pourquoi j’ai eu tort de tourner la page.
Microsoft Domain Specific Language Tools sont des outils pour implémenter des DSL, des langages spécifiques conçus pour répondre à un problème donné. Ils sont fournis sous la forme d’un SDK qui peut être installé sur Visual Studio 2005 Professional.
Ici, il peut y avoir confusion. Il ne faut pas voir les DSL Tools comme une partie intégrante de Visual Studio mais plutôt comme une solution à part entière (standalone).

• « Un outil pour fabriquer des outils » : cette définition, celle de Microsoft, souligne la différence avec les outils UML. La démarche UML/MDA (Model Driven Architecture) est jalonnée d’une série de transformations de modèles (éléments UML génériques), depuis d’un haut niveau d’abstraction, le CIM (Computation Independent Model), jusqu’à l’implémentation, le PSM (Platform Specific Model).
  C’est la différence clé. Ce que Microsoft propose :
• Dans une première phase, l’architecte construit la définition du langage pour le modèle spécifique, avec ses règles, ses validations, ses entités et leurs relations (cette spécificité garantit l’adéquation avec le domaine) et il intègre le tout dans un outil de modélisation à utiliser par les développeurs 
   
• Dans une deuxième phase, il laisse au développeur le soin d’utiliser cet outil et ses éléments pour définir l’implémentation de son application.

J’ai jusqu’à maintenant parlé des DSL dans leur aspect vertical, c’est-à-dire propre à un domaine métier. Je vais illustrer l’utilisation des DSL dans une démarche plutôt horizontale, technique, pour apporter la preuve de leur flexibilité.
Ma démonstration traite du pattern MVP (Model View Presenter). Je constate que le concept de code behind est souvent mal compris par les développeurs. Certains ont tendance à y inclure beaucoup de logique applicative. Or, tout ce qui est dans le code behind n’est ni testable, ni réutilisable !
Le pattern de conception MVP apporte une réponse intéressante à cette problématique en déportant la logique de présentation dans un composant spécifique testable indépendant de la technologie choisie pour la vue. Il offre ainsi un découpage des responsabilités sain et robuste.
Mais n’allons pas plus loin dans la description de ce pattern (voir les références pour plus d’informations) et revenons aux DSL Tools.
Il revient à l’architecte :

• De définir le méta-modèle du MVP (la sémantique du langage)
• De créer un outil intégrable à l’environnement de développement Visual Studio et de définir son apparence
•  D’assurer la validité du modèle implémenté en s’appuyant sur le méta-modèle par la définition de règles de validation (la syntaxe du langage).

A partir d’un nouveau projet de type « Langage Minimal », l’architecte définit le méta-modèle, composé des éléments suivants :

• View (qui correspond à une vue, de type WinForm, WebForm, XAML,…)
• ViewContract (une interface pour la vue)
• Presenter
• Model (référence un élément métier)

…et des relations suivantes :

• Un ViewContract est implémenté par une ou plusieurs View
• Un Presenter manipule une vue par son contrat (ViewContract)
• Un Presenter « utilise » un élément du modèle

Sont ensuite définies les règles de validation qui permettent d’assurer la cohérence :

• Erreur bloquante si une View n’implémente aucun ViewContract
• Erreur bloquante si un ViewContract n’est référencée par aucun Presenter
• Message d’alerte si un ViewContract n’est implémenté par aucune View
• Message d’alerte si un Presenter ne référence aucun ViewContract.

  using System;
using Microsoft.VisualStudio.Modeling.Validation;
using System.Globalization;
namespace Valtech.ModelViewPresenter
{
    ///
    /// Validation checks that will be applied to every ViewContract
    ///
    [Microsoft.VisualStudio.Modeling.Validation.ValidationState
    (Microsoft.VisualStudio.Modeling.Validation.ValidationState.Enabled)]
    public partial class ViewContract
    {
        ///
        /// PresenterReference : Validates that ViewContract is manipulated by a Presenter
        ///
        ///            

The initBinder method on the binderObject subscribes it to the deffirent events of the datagrid.

then treatement can be added for the deffirent events.

DataBinders with xml mappping can be provided, so that reflexion can be used to map model to the dataBinderObject at run time.

i promise more explaination about benefits of applying such a pattern, and the more sophisticated Demo.

for now i ll let you view the diagrams, feel free to comment!

Class Diagram:

Sequence Diagram :