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

Question

Я использую 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 аксессора называется три раза. Один раз с новым значением, но только в новом экземпляре пользователя, затем один раз со старым значением, снова в новом экземпляре и, наконец, со старым значением существующего экземпляра.

Чувствуя себя немного, я проверил свойства, созданные дизайнером, и они тоже называются три раза (почти) одинаково. Единственное отличие состоит в том, что последний вызов содержит новое значение для свойства.

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

Answer 1

Я заметил что-то подобное, когда я дал Linq 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 создавать объекты для вашей информации о профиле: все будет «стандартным», и вам не придется прибегать к каким-то «взломам» ...