Question

I am using ASP.NET DynamicData (based on LINQ to SQL) on my site for basic scaffolding. On one table I have added additional properties, that are not stored in the table, but are retrieved from somewhere else. (Profile information for a user account, in this case).

They are displayed just fine, but when editing these values and pressing “Update”, they are not changed.

Here’s what the properties look like, the table is the standard aspnet_Users table:

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

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

When I fired up the debugger, I’ve noticed that for each update the set accessor is called three times. Once with the new value, but on a newly created instance of user, then once with the old value, again on an new instance, and finally with the old value on the existing instance.

Wondering a bit, I checked with the properties created by the designer, and they, too, are called three times in (almost) the same fashion. The only difference is, that the last call contains the new value for the property.

I am a bit stumped here. Why three times, and why are my new properties behaving differently? I’d be grateful for any help on that matter! =)

Answer 1

I observed something similar when I let Linq to SQL use stored procedures for inserting/updating. I am not sure if I remember correctly, but I think that Linq to SQL uses these three instances of the entity class to figure out what changed so that the required SQL statement can be built.

I see basically two options (though I am not sure if this really works):

1. You could probably store the extra field(s) in the “OnValidate” event of the entity.
2. You could overwrite the partial methods for inserting/updating. In that case you will also need to take care of storing the entity in the database (e.g. with stored procedure).

The property would look then like this:

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;                      
    }
}   

In both cases you have the problem that you might update the extra fields though the update of the rest of the entity fails. This was of course also a problem with your initial approach.

I think the best solution would be to implement your own profile provider and store the profile information in your own tables. If you do that you could let Linq to SQL create entities for your profile information: Everything would be “standard” and you would not have to resort to some kind of “hack”…