Ce tutoriel a pour but de décrire les étapes à suivre pour mettre en place RIA, mais en tenant compte de l'expérience acquise au cours de ces derniers mois (réalisation de projets qui utilisent RIA).

Il aborde donc la technologie et expose les solutions mises en place pour faciliter les phases de développement (gestion des erreurs, conflits, classe partielle pour définir le "DomainService", etc.). Il s'agit, en quelque sorte, d'ébauches de "bonnes conduites" (en toute modestie) qui ont facilité le développement des logiciels.

La rédaction de cet aide mémoire a été réalisée dans le cadre suivant :

• Framework.net 3.5 sp1 ;
• Mapping relationnel objet : « Entity Framework » ;
• Silverlight 3 ;
• WCF RIA Services pour le Framework 3.5 (version datant du PDC).

Les exemples éventuels liés à ce document se baseront donc sur cet environnement, néanmoins, le passage à la version 4 ne remet pas en cause ce tutoriel (logiquement).

Cliquez ici pour récupérer les sources de l'exemple.

La base de données utilisée est présente dans les sources (répertoire App_Data du projet Web).
Pour exécuter le projet, vous devez monter la base de données (Northwind) dans une instance SQL Server puis modifier la chaine de connexion dans le fichier web.config.

Attention : la chaine de connexion n'est pas une chaine SQL Server classique. Il s'agit d'une chaine de connexion Entity Framework. Dès lors, la chaine de connexion à la base de données est incluse dans la chaine Entity Framework. Je vous conseille donc de ne modifier que les éléments propre à SQL Server inclus dans la chaine Entity Framework (situés vers la fin de la chaine).

N'oubliez pas de démarrer la solution par le projet web : l'application Silverlight ne peut pas démarrer toute seule.

Une dernière information : le code source et le tutoriel se complètent. Je vous conseille donc de consulter les deux simultanément.

Bonne lecture !

RIA est une couche logicielle (API) qui va permettre de simplifier l'implémentation de la communication entre les tiers d'une application n-tiers (entre la partie client léger -silverlight ici- et le serveur web).

Pour ce faire, RIA s'appuie sur quattre mécanismes :

• centralisation de la définition des règles de validation des données.
  Le mécanisme est basé sur la décoration des classes et membres par des attributs dans un fichier de métadonnées (nous y reviendrons plus tard) ;
  
• le modèle de données est diffusé côté client (on ne manipule donc que des objets métiers qui correspondent au modèle Entity Framework) ;
  
• proxy de communication qui utilise Linq pour requêter (ADO.NET DataServices). La requête Linq est transformée en url de requêtage pour interroger le serveur, récupérer les résultats et mapper les résultats en objets métiers ;
  
• génération automatique des points de terminaison (WCF) lors du déploiement de l'application (au nombre de 3 : WsHttpBinding, BinaryHttpBinding et BasicHttpBinding).
  

WsHttpBinding, BinaryHttpBinding et BasicHttpBinding sont trois types de liaisons WCF.

WCF (Windows Communication Fundation) est un mécanisme qui permet aux applications de communiquer facilement ensemble.

Cette technologie présente comme avantage de séparer l'implémentation (code), des aspects techniques utilisés pour négocier la communication entre application (WebService, Binaire, etc).
Cette technologie repose sur un principe : ABC - Address, Binding, Contrat.

Address - Tout point de terminaison dispose d'une adresse ;
Binding - Tout point de terminaison est exploitable suivant certaines règles (protocole, sécurité, quotas de données, etc) ;
Contrat - Tout point de terminaison est lié à un contrat de service ; 

Dans notre cas de figure :

- BasicHttpBinding définit un ensemble de règles simple reflétant un WebService de type asmx ;
- WsHttpBinding s'appuie sur BasicHttpBinding, en lui ajoutant des notions de sécurité (couche transport, session, etc) ;
- BinaryHttpBinding permet la communication binaire entre applications. Silverlight exploite nativement ce point de terminaison ;

Ci dessous, un résumé des bindings Wcf existant et leurs caractéristiques respectives.
Notez que seul le BasicHttpBinding ne dispose pas d'un transport sécurisé (T).

Cette image a été trouvée sur le blog suivant : http://bloggingabout.net/blogs/dennis/

Attention : si le serveur s'exécute sur Windows 2008, le serveur Web est forcément IIS 7.x, il est indispensable que les composants Windows "Microsoft .Net Framework 3.5.x", "WCF Http Activation" et "WCF Non Http Activation" soient activés.

En résumé, le client va requêter une source de données (DataContext) en utilisant Linq sur un proxy. Le proxy va se charger de traduire la requête en url, de se connecter au serveur pour la lui transmettre et enfin, de récupérer les résultats et effectuer le mapping relationnel objet (côté client).

Il n'est donc plus nécessaire d'implémenter un Web Service (ou autre) pour les opérations de création, mise à jour et de récupération d'objets (dans la majorité des cas) !

It's Magic !

Grâce à ce mécanisme, le travail des équipes de développement se concentre alors sur les aspects métiers de l'application n-tiers. Cela permet de gagner du temps précieux sur l'implémentation des couches de communication entre composants applicatifs de l'application n-tiers (vécu !).

En d'autres termes, il n'est plus nécessaire de se préoccuper du moyen utilisé pour effectuer les accès aux données du SI (type Web Service ou autre). RIA se charge de cela en offrant au développeur un proxy à instancier et à interroger (en Linq). RIA peut prendre également en charge les mécanismes de validation, insertion, modification, suppression de données.

Le tutoriel n'en parle pas (car beaucoup d'écrits existent à ce sujet), néanmoins, pour créer un projet Silverlight supportant RIA, Il vous suffit d'activer la boite à cocher Wcf Ria Services lors de la création de l'application Silverlight au sein du projet Web.

Il est également possible d'activer RIA après avoir créé le projet Silverlight : vous devez vous rendre dans les propriétés du projet Silverlight, et activer WCF Ria Service en précisant le projet Web où se trouvent les services.

Pour l'exemple, je me base sur un modèle Entity Framework. Mais il demeure possible d'utiliser d'autres frameworks de mapping relationnel objet.

Le modèle de données de l'exemple est construit sur la Bdd Northwind (histoire de ne pas utiliser mes bases client.

Les tables retenues sont :

III-A. Création du "Domain Service Class"▲

namespace NorthWindRIA.Web.Metier.Services
{
    using System.Web.DomainServices.Providers;
    using System.Web.Ria;
    using NorthWindRIA.Web.Metier;
        
    // [RequiresAuthentication] => Attribut qui décommenté, entraine la nécessité dêtre authentifié (au sens ASP.net) pour attaquer le service,
    /// <summary>
    /// Classe de base du Referentiel.
    /// </summary>
    [EnableClientAccess()] // Indique que le service est accessible !
    public partial class Referentiel : LinqToEntitiesDomainService<NorthwindEntities>
    {
        // contient ce qui est commun Ã&nbsp; toutes les déclarations partielles : attributs, etc
    }
}

namespace NorthWindRIA.Web.Metier.Services
{
    using System.Data;
    using System.Linq;
    using System.Web.DomainServices.Providers;
    using NorthWindRIA.Web.Metier;


    // Classe partielle Referentiel (cf Referentiel.cs pour les informations de la classe)
    // ce fichier contient la description des services dispo pour les entités Customers
    public partial class Referentiel : LinqToEntitiesDomainService<NorthwindEntities>
    {
        /// <summary>
        /// Retourne la Query de base utilisée lorsqu'un client effectue une requête de sélection
        /// </summary>
        /// <returns>Query sur les entités <see cref="Customers"/> servant de base à toutes les requêtes de sélection provenant des app clientes.</returns>
        public IQueryable<Customers> GetCustomers()
        {
            return this.ObjectContext.Customers;
        }

        /// <summary>
        /// Effectue une insertion (si absent, la tentative d'insertion d'une entité entraine une exception => car interdit)
        /// </summary>
        /// <param name="customers">Client à insérer</param>
        public void InsertCustomers(Customers customers)
        {
            this.ObjectContext.AddToCustomers(customers);
        }

        /// <summary>
        /// Effectue une modification (si absent, la tentative de mise à jour d'une entité entraine une exception => car interdit)
        /// </summary>
        /// <param name="customers">Client à modifier</param>
        public void UpdateCustomers(Customers currentCustomers)
        {
            if ((currentCustomers.EntityState == EntityState.Detached))
            {
                this.ObjectContext.AttachAsModified(currentCustomers, this.ChangeSet.GetOriginal(currentCustomers));
            }
        }

        /// <summary>
        /// Effectue une suppression (si absent, la tentative de suppression d'une entité entraine une exception => car interdit)
        /// </summary>
        /// <param name="customers">Client à supprimer</param>
        public void DeleteCustomers(Customers customers)
        {
            if ((customers.EntityState == EntityState.Detached))
            {
                this.ObjectContext.Attach(customers);
            }
            this.ObjectContext.DeleteObject(customers);
        }
    }
}

#pragma warning disable 649    // disable compiler warnings about unassigned fields

namespace NorthWindRIA.Web.Metier
{
    using System;
    using System.Collections.Generic;
    using System.ComponentModel;
    using System.ComponentModel.DataAnnotations;
    using System.Data.Objects.DataClasses;
    using System.Linq;
    using System.Web.DomainServices;
    using System.Web.Ria;
    using System.Web.Ria.Services;


    // The MetadataTypeAttribute identifies CustomersMetadata as the class
    // that carries additional metadata for the Customers class.
    [MetadataTypeAttribute(typeof(Customers.CustomersMetadata))]
    public partial class Customers
    {

        // This class allows you to attach custom attributes to properties
        // of the Customers class.
        //
        // For example, the following marks the Xyz property as a
        // required field and specifies the format for valid values:
        //    [Required]
        //    [RegularExpression("[A-Z][A-Za-z0-9]*")]
        //    [StringLength(32)]
        //    public string Xyz;
        internal sealed class CustomersMetadata
        {

            // Metadata classes are not meant to be instantiated.
            private CustomersMetadata()
            {
            }

            public string Address;

            public string City;

            public string CompanyName;

            [StringLength(25)] // Attribut ajouté pour limiter le nombre de caractères
            public string ContactName;

            public string ContactTitle;

            public string Country;

            public string CustomerID;

            public string Fax;

            public EntityCollection<Orders> Orders;

            public string Phone;

            public string PostalCode;

            public string Region;
        }
    }
}

#pragma warning restore 649    // re-enable compiler warnings about unassigned fields

Le chargement des données demeure, somme toute, assez simple.

Il se réalise en trois étapes :

• Instanciation du contexte de données :

 monContexte = new Referentiel(); // Où Referentiel est le nom de la classe DomainService<BR>

• Création de la requête Linq d'interrogation :

 query = monContexte.GetCustomersQuery().Where(cust => cust.ContactName.StartsWith("A"));

• Exécution et récupération du résultat (s'il y a lieu). PS : La récupération peut se réaliser par expression lambda ou par évènement.
  Dans les deux cas, l'objet qui contient le résultat de la requête est de type LoadOperation. C'est donc avec ce dernier qu'il faut traiter les erreurs éventuelles, et récupérer les résultats (si nécessaire).

 monContexte.Load<Customers>(
       query,
       loadOp =>
       {
       	// Code de l'expression lambda
       }, 
       false);

// ...
     // Exécute la requête !
     var loadOp = monContexte.Load<Customers>(query, false);
     loadOp.Completed += new EventHandler(loadOp_Completed); // abonnement du delegate à la méthode loadOp_Completed

//...

// Code de la méthode abonnées au retour de l'évènement...
private void loadOp_Completed(object sender, EventArgs e)
{
     var loadOp = sender as LoadOperation<Customers>; // le sender est l'objet LoadOperation !
     // Suite du code !
}

Lorsque je parle de la récupération de données, j'utilise le terme "éventuellement". Car lors de la récupération de données, RIA met à jour les collections concernées, intrinsèques du Contexte utilisé pour effectuer la requête.
Donc, rien n'empêche d'utiliser ces ObservablesCollections (qui nous informent lorsqu'elles sont modifiées), par Binding (par exemple). C'est le cas dans l'exemple lié au tutoriel.

Lorsque l'on parle de soumission de modifications, on entend par là toute opération (insertion, mise à jour, suppression) effectuée entre le moment où les données sont extraites (ou depuis la dernière mise à jour) et le moment où j'effectue la demande de soumission.

La soumission de modifications n'est pas complexe en soi, mais il faut respecter une certaine logique

Lorsque j'extrais un objet du serveur, on peut voir que j'utilise un contexte de données. Ce contexte reste lié à mon objet (un objet ne pouvant être lié qu'à un contexte de données) durant la vie de l'objet (sauf si je détache l'objet du contexte).

J'ajouterais que RIA a la capacité de détecter les objets et propriétés modifiées, et dans une certaine mesure (nous le verrons plus tard), de participer à la gestion des conflits.

Revenons donc à la soumission : il suffit d'appeler la méthode SubmitChanges du contexte de données qui a extrait les données, bien évidemment, après la modification des données.

Je vous invite à consulter l'exemple fourni.
Voici sa logique :

• le DataContext de l'écran contient le contexte de données qui extrait ces dernières ;
  
  
• la propriété ItemsSource de la grid est liée (Binding Xaml) à l'observable collection cachée derrière la propriété Customers du DataContext
  Donc, dès que la collection Customers change, la grid change sont contenu ;
  
• la propriété IsEnable du bouton de mise à jour est liée (Binding Xaml) à la propriété HasChanges du DataContext.
  Donc, lorsque l'utilisateur modifie une valeur, le contexte de données informe le bouton qu'il peut s'activer !
  

Lorsque l'utilisateur clique sur le bouton permettant la mise à jour, le code suivant est appelé :

monContexte.SubmitChanges(
     submitOp =>
     {
          // code qui traite le retour de màj avec la gestion des erreurs
          if (submitOp.HasError)
          {
               submitOp.MarkErrorAsHandled(); // évite de remonter l'exception à l'App.Application_UnhandledException

               if (submitOp.Error != null)
               {

               }
          }
     }, 
	 null);
	 

Dans ce code, je traite le retour de l'appel de mise à jour par une expression lambda. Néanmoins, à l'instar de la récupération de données, il demeure possible de réaliser cette opération de façon évènementielle. L'objet manipulé n'est pas de type LoadOperation mais plutôt SubmitOperation.

Information : je vous invite à modifier une valeur (ajouter une lettre par exemple) puis à supprimer votre modification, vous verrez que le bouton Mettre à jour les données s'active et se désactive automatiquement. Ceci est réalisé en liant (Binding) la propriété HasChanges du contexte de données à la propriété IsEnabled du bouton (voir code Xaml).

La gestion des exceptions provenant des accès aux données demeure, en définitive, assez simple à gérer.

Considérons les deux côtés applicatifs, à savoir : côté client (Silverlight) et côté Serveur.

VI-A. Côté client : Silverlight▲

monContexte.Load<Customers>(
    monContexte.GetCustomersQuery(),
    <BR>    // EXPRESSION LAMBDA : 
    loadOperation =>
         {
              if (loadOperation.HasError)
              {
                  MessageBox.Show(loadOperation.Error.Message);
                  loadOperation.MarkErrorAsHandled();
			  }
         }, 
    // FIN D'EXPRESSION LAMBDA
    null);

// Appel de Submit changes en passant une expression lambda appelée au retour de l'appel !
monContexte.SubmitChanges(
     submitOp => // Expression lambda !
     {
          // code qui traite le retour avec gestion des erreurs
          
          if (submitOp.HasError) // Erreur présente ?
          {
               submitOp.MarkErrorAsHandled(); // permet d'éviter de diffuser l'exception comme irrémédiable !

               if (submitOp.Error != null)
               {
					// traitement de l'objet Erreur (type Exception)
               }
               // traitement commun à toutes les erreurs
          }
     }, 
	 null);

namespace NorthWindRIA
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Windows.Ria;

    /// <summary>
    /// Classe d'extension sur un <see cref="LoadOperation{T}"/>
    /// </summary>
    public static class LoadOperationExtender
    {
        /// <summary>
        /// Traite le retour d'un appel au serveur pour les LoadOperations.
        /// Affiche éventuellement un message d'erreur à l'utilisateur si une erreur s'est produite.
        /// </summary>
        /// <typeparam name="T">Type d'objet retourné par la LoadOperation (<see cref="Entity"/>>)</typeparam>
        /// <param name="loadOp"><see cref="LoadOperation"/> qui a été utilisée pour l'appel au serveur</param>
        /// <returns><see cref="List{T}"/>La liste est vide en cas d'erreur (non nulle)</returns>
        public static List<T> TraiteRetour<T>(this LoadOperation<T> loadOp)
            where T : Entity
        {
            List<T> returnedList = new List<T>(); // par sécurité, la liste n'est jamais nulle !

            if (loadOp.Error != null)
            {
                loadOp.MarkErrorAsHandled();

                /* Méthode statique située dans la classe App qui permet de 
                 * traiter les erreurs de façon commune à toute l'app */
                App.TraiteErreur(loadOp.Error); 
            }
            else if (loadOp.Entities == null && !loadOp.Entities.Any())
            {
                /* Méthode statique située dans la classe App qui permet de 
                 * traiter les erreurs de façon commune à toute l'app */
                App.TraiteErreur("Le serveur n'a renvoyé aucune entité de type " + typeof(T).ToString() + " ! ");
            }
            else
            {
                returnedList = new List<T>(loadOp.Entities);
            }

            return returnedList;
        }
    }
}

}

namespace NorthWindRIA
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Windows.Ria;

    /// <summary>
    /// Extender de la classe <see cref="SubmitOperation"/>
    /// </summary>
    public static class SubmitOperationExtender
    {
        /// <summary>
        /// Traite le retour d'un appel au serveur pour les <see cref="SubmitOperation"/>.
        /// Affiche éventuellement un message d'erreur à l'utilisateur si une erreur s'est produite.
        /// </summary>
        /// <param name="submitOp"><see cref="SubmitOperation"/> qui a été utilisée pour l'appel au serveur</param>
        /// <returns>Boolean : False si le retour est en erreur</returns>
        public static Boolean TraiteRetour(this SubmitOperation submitOp)
        {
            Boolean returned = true;

            if (submitOp.Error != null)
            {
                submitOp.MarkErrorAsHandled();
                returned = false;

                /* Méthode statique située dans la classe App qui permet de 
                 * traiter les erreurs de façon commune à toute l'app */
                App.TraiteErreur(submitOp.Error);
            }

            return returned;
        }
    }
}

}

namespace NorthWindRIA
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Windows.Ria;

    /// <summary>
    /// Classe d'extension sur un <see cref="InvokeOperation"/>
    /// </summary>
    public static class InvokeOperationExtender
    {
        /// <summary>
        /// Traite le retour d'un appel au serveur pour les <see cref="InvokeOperation"/>.
        /// Affiche éventuellement un message d'erreur à l'utilisateur si une erreur s'est produite.
        /// </summary>
        /// <param name="invokeOp"><see cref="InvokeOperation"/> qui a été utilisée pour l'appel au serveur</param>
        /// <returns>Boolean : False si le retour est en erreur</returns>
        public static Boolean TraiteRetour(this InvokeOperation invokeOp)
        {
            Boolean returned = true;

            if (invokeOp.Error != null)
            {
                invokeOp.MarkErrorAsHandled();
                returned = false;

                /* Méthode statique située dans la classe App qui permet de 
                 * traiter les erreurs de façon commune à toute l'app */
                App.TraiteErreur(invokeOp.Error); 
            }

            return returned;
        }
    }
}


}

var results = loadOp.TraiteRetour(); // pour une LoadOperation


if(submitOp.TraiteRetour()) // pour une SubmitOperation 
{
	// ...
}
else
{
	// ...
}


if(submitOp.TraiteRetour()) // pour une InvokeOperation 
{
	// ...
}
else
{
	// ...
}

     <customErrors mode="On" defaultRedirect="?" />

VI-B. Côté serveur : DomainService▲

[EnableClientAccess()]
public partial class Referentiel : LinqToEntitiesDomainService<NorthwindEntities>
{
     // contient ce qui est commun Ã&nbsp; toutes les déclarations partielles : attributs, etc

     /// <summary>
     /// Traite les erreurs avant de les renvoyer au client !
     /// </summary>
     /// <param name="errorInfo"></param>
     protected override void OnError(DomainServiceErrorInfo errorInfo)
     {
          base.OnError(errorInfo);
          // Traite l'erreur
     }
}

Lors d'une mise à jour de nos données, un conflit peut apparaître si (par malheur) la donnée concernée a été modifiée depuis notre dernière extraction.

Traditionnellement, un ensemble de règles existent pour traiter cette situation embarrassante.

Tout d'abord, nous pourrions considérer que le dernier a toujours raison : dans ce cas, inutile de faire quoi que ce soit, Entity gère très bien les choses sans activer la gestion des conflits !

Nous aurions pu, également, choisir que le plus ancien a toujours raison... (Ou pas).

Enfin, nous pouvons implémenter notre propre logique de résolution de conflits, automatique ou avec prise de décision de la part de l'utilisateur.

Dans le premier cas (automatique), nous implémenterons certainement la logique du code sur le serveur. Dans le second, il faudra remonter l'erreur au client, et laisser l'application cliente se dépêtrer avec celle ci.

Quoi qu'il en soit, voici la logique qui permet de provoquer un conflit de données :

• utilisateur 1 affiche les données ;
• utilisateur 2 affiche les données ;
• utilisateur 1 modifie un enregistrement (update, delete) ;
• utilisateur 2 tente de modifier le même enregistrement, même champ ;
• utilisateur 2 est averti que la donnée qu'il tente de mettre à jour est en conflit, car sa source ne correspond plus à celle actuellement en base de données.

Si nous ne choisissons pas la situation par défaut (le dernier qui a parlé a toujours raison), il est indispensable de permettre la gestion des conflits.
Car si RIA prend en compte les mécanismes de gestion concurrentielle, encore faut-il que la couche d'accès aux données soit la source de cette prise en compte.
En d'autres termes, dans EF (pour le cas qui nous concerne), il faut activer la gestion concurrentielle sur les champs des objets manipulés.

VII-A. Côté serveur▲

protected override bool ResolveChangeSet(ChangeSet changeSet)
{
     return base.ResolveChangeSet(changeSet); // remplacer ce code par le notre.
}

VII-B. Côté client (Silverlight)▲

private void ResolveConflict(Customers custInConflict)
{
    // Trois entités sont considérées pour la résolution :
    //  - Entité actuellement extraite, => monCustOriginal
    //  - Entité actuellement en base de données, => custActuellementEnBdd 
    //  - Entité qui a été modifiée par l'utilisateur, => monCustModifie

    Customers monCustOriginal, monCustModifie, custActuellementEnBdd, custChoisitPourSvgBdd = null;

    // Création du Contexte de données pour la résolution de conflit :
    Referentiel dataCtx = new Referentiel();

    // Récup de la version actuellement en Bdd
    var query = dataCtx.GetCustomersQuery().Where(cust => cust.CustomerID == custInConflict.CustomerID);
    dataCtx.Load<Customers>(
        query,
        loadOp =>
        {
            // Expression lambda appelée lorsque le customer actuellement en Bdd est récupéré
            var results = loadOp.TraiteRetour();

            if (results.Any()) // Le customer existe-t-il en Bdd ?
            {
                // Redirection dans les variables ad hoc => clarifier le code
                custActuellementEnBdd = results.First();
                monCustOriginal = custInConflict.GetOriginal() as Customers;
                monCustModifie = custInConflict;

                // Affichage d'un écran pour sélectionner le Customer à garder,
                CustConflictResolver win = new CustConflictResolver()
                {
                    CustomerBdd = custActuellementEnBdd,
                    CustomerOriginal = monCustOriginal,
                    CustomerSelectionne = monCustModifie
                };

                // Lorsque la fenêtre se ferme, traitement de la résolution de conflits (abonnementà l'évènement Closed en utilisant une Lambda d'exécution.
                win.Closed += (sender, e) =>
                {
                    if (win.DialogResult != null && win.DialogResult.Value) // Utilisation a-t-il annulé ?
                    {
                        custChoisitPourSvgBdd = win.CustomerSelectionne; // customer sélectionné !

                        // Sauvegarde du Customer souhaité (ou rien si l'heureux élu est celui déjà en bdd)
                        if (custChoisitPourSvgBdd != custActuellementEnBdd)
                        {
                            // L'objet sur lequel on bosse est custActuellementEnBdd 
                            // car c'est celui qui est attaché au contexte de données local dataCtx
                            custActuellementEnBdd.RemplaceMesMembresParCeuxDe(custChoisitPourSvgBdd);

                            // Enregistrement de custActuellementEnBdd modifié !
                            dataCtx.SubmitChanges(
                                submitOp =>
                                {
                                    if (submitOp.TraiteRetour())
                                    {
                                        // Pour éviter un rafraichissement complet ! on détache l'objet 
                                        // pour pouvoir le rattacher au contexte de données principal (cf. RemplaceCustomer)
                                        dataCtx.Customers.Detach(custActuellementEnBdd);
                                        this.RemplaceCustomer(custInConflict, custActuellementEnBdd);
                                    }
                                },
                                false);
                        }
                    }
                };
                win.Show();
            }
        },
        false);
}

 monContexte.Customers.Add(nouvelleEntiteCustomer);
 monContexte.SubmitChanges(); // peut être appelé pour enregistrer plusieurs modifications en une fois !  

Je tiens à remercier toutes les personnes qui ont permis à ce tutoriel d'exister : Adeline, Mélanie, Louis-Guillaume, Jérome, nico-pyright et jacques_jean. Sans oublier Caro-Line (pour le dernier "tuto" => "tutoriel") :).