ASP.NET DynamicData: что происходит во время обновления? - PullRequest
Новая
       16

ASP.NET DynamicData: что происходит во время обновления?

1 голос
/ 20 апреля 2010

Я использую ASP.NET DynamicData (на основе LINQ to SQL) на своем сайте для базовых строительных лесов. В одну таблицу я добавил дополнительные свойства, которые не хранятся в таблице, а извлекаются откуда-то еще. (Информация профиля для учетной записи пользователя, в данном случае).

Они отображаются просто отлично, но при редактировании этих значений и нажатии «Обновить» они не изменяются.

Вот как выглядят свойства, таблица является стандартной таблицей 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();                
        }
    }

Когда я запустил отладчик, я заметил, что для каждого обновления метод доступа set вызывается три раза. Один раз с новым значением, но на вновь созданном экземпляре пользователя, затем один раз со старым значением, снова на новом экземпляре и, наконец, со старым значением на существующем экземпляре.

Интересно, я проверил свойства, созданные дизайнером, и они тоже трижды вызываются (почти) одинаково. Разница лишь в том, что последний вызов содержит новое значение для свойства.

Я немного озадачен здесь. Почему три раза, и почему мои новые свойства ведут себя по-разному? Буду благодарен за любую помощь по этому вопросу! =)

1 Ответ

1 голос
/ 25 апреля 2010

Я наблюдал нечто подобное, когда позволял Linq to SQL использовать хранимые процедуры для вставки / обновления. Я не уверен, правильно ли я помню, но я думаю, что Linq to SQL использует эти три экземпляра класса сущностей, чтобы выяснить, что изменилось, чтобы можно было построить требуемый оператор SQL.

Я вижу в основном два варианта (хотя я не уверен, действительно ли это работает):

  1. Возможно, вы можете сохранить дополнительные поля в событии "OnValidate" объекта.
  2. Вы можете перезаписать частичные методы для вставки / обновления. В этом случае вам также необходимо позаботиться о сохранении сущности в базе данных (например, с помощью хранимой процедуры).

Тогда свойство будет выглядеть так: 

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

В обоих случаях возникает проблема, связанная с тем, что вы можете обновить дополнительные поля, хотя обновление остальной части сущности завершается неудачно. Это, конечно, также было проблемой с вашим первоначальным подходом.

Я думаю, что наилучшим решением было бы реализовать вашего собственного провайдера профилей и хранить информацию о профиле в ваших собственных таблицах. Если вы сделаете это, вы сможете позволить Linq to SQL создавать сущности для информации вашего профиля: все будет «стандартно», и вам не придется прибегать к какому-то «хаку» ...

...