Почему этот код делает, если (sz! = Sz2) sz = sz2?

Question

Впервые я создал linq to sql classes. Я решил посмотреть на класс и нашел это.

Что ... почему это происходит, если (sz! = Sz2) {sz = sz2; }. Я не понимаю Почему набор не генерируется как this._Property1 = value?

    private string _Property1;
    [Column(Storage="_Property1", CanBeNull=false)]
    public string Property1
    {
        get
        {
            return this._Property1;
        }
        set
        {
            if ((this._Property1 != value))
            {
                this._Property1 = value;
            }
        }
    }

Answer 1

Обновляет свойство только в том случае, если оно изменилось. Вероятно, это основано на предположении, что сравнение обходится дешевле, чем обновление ссылки (и всего необходимого управления памятью), которая может быть задействована.

Answer 2

Где ты это видишь? Обычные сгенерированные LINQ-to-SQL свойства выглядят следующим образом:

private string _Property1;
[Column(Storage="_Property1", CanBeNull=false)]
public string Property1 {
    get {
        return this._Property1;
    }
    set {
        if ((this._Property1 != value)) {
           this.OnProperty1Changing(value);
           this.SendPropertyChanging();
           this._Property1 = value;
           this.SendPropertyChanged("Property1");
           this.OnProperty1Changed();
       }
    }
}

И теперь совершенно ясно, что устройство не должно отправлять уведомления об изменении / изменении свойства, когда свойство фактически не меняется.

Теперь выясняется, что OnProperty1Changing и OnProperty1Changed являются partial методами, так что если вы не объявляете тело для них в другом месте, вызовы этих методов не будут скомпилированы в окончательную сборку (так что если скажем, вы искали в Reflector вы бы не увидели эти звонки). Но SendPropertyChanging и SendPropertyChanged - это protected методы, которые не могут быть скомпилированы.

Итак, возможно, вы изменили настройку, которая предотвращает генерацию кода при изменении / изменении уведомлений?

Answer 3

Установка поля не вызовет уведомлений об изменении свойств, поэтому причина не в этом.

Я бы предположил, что этот выбор дизайна был обусловлен чем-то вроде следующего:

Эта строка является неизменным ссылочным типом. Поэтому оригинальные и новые экземпляры являются взаимозаменяемыми. Однако первоначальный экземпляр, возможно, был дольше и поэтому в среднем собирать его может быть немного дороже (*). Поэтому производительность может быть лучше, если исходный экземпляр сохраняется, а не заменяется новым идентичным экземпляром.

(*) Новое значение в большинстве случаев было только назначено и не будет повторно использовано после установки свойства. Таким образом, очень часто объект Gen0 эффективно собирать, тогда как генерация GC исходного значения неизвестна.

Если эти рассуждения верны, я не ожидаю увидеть тот же шаблон для свойств типа значения (int, double, DateTime, ...).

Но, конечно, это всего лишь предположение, и я могу ошибаться.

Answer 4

Это происходит из корня ObjectPascal Хейлсберга .... по крайней мере, так реализована большая часть VCL Borland Delphi ...;)

Answer 5

Похоже, здесь происходит упорство. Если что-то использует отражение (или pointcut, или что-то) для создания запроса SQL UPDATE при изменении _Property1, то обновление поля будет намного дороже, чем сравнение.