Comment tirer parti de la vérification de la concurrence avec les entités de suivi automatique POCO EF 4.0 dans un scénario N-Tier?

Question

J'utilise VS1010RC avec les modèles T4 POCO auto-suivi.

Dans mon WCF méthode de service de mise à jour, je me sers quelque chose de similaire à ce qui suit:

using (var context = new MyContext()) 
{ 
    context.MyObjects.ApplyChanges(myObject); 
    context.SaveChanges(); 
} 

Cela fonctionne bien jusqu'à ce que je mets ConcurrencyMode = fixe sur l'entité puis-je obtenir une exception. Il semble que le contexte ne connaisse pas les valeurs précédentes car l'instruction SQL utilise la valeur des entités modifiées dans la clause WHERE.

Quelle est la bonne approche lors de l'utilisation de ConcurrencyMode = Fixed?

Answer 1

Les valeurs précédentes doivent figurer dans votre objet.

Disons que vous avez une propriété ConcurrencyToken:

public class MyObject 
{ 
    public Guid Id { get; set; } 
    // stuff 
    public byte[] ConcurrencyToken { get; set; } 
} 

vous pouvez maintenant définir ConcurrencyMode.Fixed sur cette propriété. Vous devez également configurer votre base de données pour la mettre à jour automatiquement.

Lorsque vous interrogez la DB, il aura une certaine valeur:

var mo = Context.MyObjects.First(); 
Assert.IsNotNull(mo.ConcurrencyToken); 

Maintenant, vous pouvez détacher ou sérialiser l'objet, mais vous devez inclure ConcurrencyToken. Ainsi, si vous placez les données d'objet sur un formulaire Web, vous devez sérialiser ConcurrencyToken en une chaîne et la placer dans une entrée masquée.

Lorsque vous ApplyChanges, vous devez inclure le ConcurrencyToken:

Assert.IsNotNull(myObject.ConcurrencyToken); 
using (var context = new MyContext()) 
{ 
    context.MyObjects.ApplyChanges(myObject); 
    context.SaveChanges(); 
} 

Ayant ConcurrencyMode.Fixed change le UPDATE SQL. Normalement, il ressemble à:

UPDATE [dbo].[MyObject] 
SET --stuff 
WHERE [Id] = @0 

Avec ConcurrencyMode.Fixed il ressemble:

UPDATE [dbo].[MyObject] 
SET --stuff 
WHERE [Id] = @0 AND [ConcurrencyToken] = @1 

... donc si quelqu'un a mis à jour la ligne entre le moment où vous lisez jeton et le moment où vous avez enregistré d'origine concurrency, le UPDATE affecte 0 ligne au lieu de 1. L'EF renvoie une erreur de concurrence dans ce cas.

Par conséquent, si tout cela ne fonctionne pas pour vous, la première étape consiste à utiliser SQL Profiler pour examiner le UPDATE généré.

Answer 2

Mark,

Les objets créés comme des « entités autovirants » ne peut pas être considéré comme Poços pur;

Voici la raison: Les STE ne fonctionnent que si votre client utilise les proxies générés à partir du modèle STE T4. Le suivi des modifications, et donc votre service, fonctionnera uniquement avec ces proxys générés.

Dans un monde POCO pur (interopérabilité, tous les clients .Net 4.0, ..), vous ne pouvez pas mettre des contraintes sur votre client.Par exemple, Facebook n'écrira pas un service qui ne peut gérer que des clients .Net 4.0.

Les STE peuvent être un bon choix dans certains environnements, tout dépend de vos besoins.