ASP.NET DynamicData: Que se passe-t-il lors d'une mise à jour?

Question

J'utilise ASP.NET DynamicData (basé sur LINQ to SQL) sur mon site pour l'échafaudage de base. Sur une table, j'ai ajouté des propriétés supplémentaires, qui ne sont pas stockées dans la table, mais sont récupérées ailleurs. (Informations de profil pour un compte d'utilisateur, dans ce cas).

Ils sont très bien affichés, mais lors de la modification de ces valeurs et en appuyant sur "Update", ils ne sont pas modifiés.

Voici ce que les propriétés ressemblent, la table est la table standard aspnet_Users:

public String Address 
    { 
     get 
     { 
      UserProfile profile = UserProfile.GetUserProfile(UserName); 
      return profile.Address; 
     } 

     set 
     { 
      UserProfile profile = UserProfile.GetUserProfile(UserName); 
      profile.Address = value; 
      profile.Save();     
     } 
    }  

Quand je pète le débogueur, je l'ai remarqué que, pour chaque mise à jour du accesseur set est appelé trois fois. Une fois avec la nouvelle valeur, mais sur une instance d'utilisateur nouvellement créée, une fois avec l'ancienne valeur, à nouveau sur une nouvelle instance, et enfin avec l'ancienne valeur sur l'instance existante. En me demandant un peu, j'ai vérifié avec les propriétés créées par le concepteur, et elles aussi sont appelées trois fois (presque) de la même manière. La seule différence est que le dernier appel contient la nouvelle valeur pour la propriété.

Je suis un peu perplexe ici. Pourquoi trois fois, et pourquoi mes nouvelles propriétés se comportent-elles différemment? Je serais reconnaissant pour toute aide à ce sujet! =)

Answer 1

J'ai observé quelque chose de similaire lorsque j'ai laissé Linq à SQL utiliser des procédures stockées pour l'insertion/la mise à jour. Je ne suis pas sûr si je me souviens correctement, mais je pense que Linq to SQL utilise ces trois instances de la classe d'entité pour comprendre ce qui a changé afin que l'instruction SQL requise puisse être construite.

Je vois essentiellement deux options (si je ne suis pas sûr si cela fonctionne vraiment):

1. Vous pourriez probablement stocker le champ supplémentaire (s) en cas « OnValidate » de l'entité.
2. Vous pouvez remplacer les méthodes partielles d'insertion/mise à jour. Dans ce cas, vous devrez également prendre soin de stocker l'entité dans la base de données (par exemple, avec la procédure stockée).

La propriété ressemblerait alors à ceci:

private string address = null; 
public string Address 
{ 
    get 
    { 
     if (this.address == null) 
     { 
      // Load on first use: This might make a problem... 
      UserProfile profile = UserProfile.GetUserProfile(UserName); 
      this.address = profile.Address; 
     } 
     return this.address; 
    } 

    set 
    { 
     this.address = value;      
    } 
} 

Dans les deux cas, vous avez le problème que vous pourriez mettre à jour les champs supplémentaires si la mise à jour du reste de l'entité échoue. C'était bien sûr aussi un problème avec votre approche initiale.

Je pense que la meilleure solution serait d'implémenter votre propre fournisseur de profil et de stocker les informations de profil dans vos propres tables. Si vous faites cela, vous pouvez laisser Linq to SQL créer des entités pour vos informations de profil: Tout serait "standard" et vous n'auriez pas à recourir à une sorte de "hack" ...