2009-12-20 7 views
1

처음으로 나는 linq to sql classes을 만들었습니다. 나는 수업을보고 이것을 발견하기로 결정했다.왜이 코드는 (sz! = sz2) sz = sz2?

왜 ... 왜 (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; 
      } 
     } 
    } 
+0

난 그냥 WTF .. –

+0

된 승인이라는 등의 카테고리가 있음을 깨달았다! 나는 그 꼬리표를 만들고 싶었다! –

+0

@ 제이슨 D : 하하, 나도 그래. 나는 진정한 WTF가 없었다. 어쩌면 이걸 제외하고. –

답변

3

필드를 설정해도 속성 변경 알림이 나타나지 않으므로 그 이유가 아닙니다.

나는이 디자인 선택은 다음과 같이 무언가에 의해 주도되었다고 생각합니다 :

그 문자열은 불변의 참조 형식입니다. 따라서 원래 인스턴스와 새 인스턴스는 서로 바꿔서 사용할 수 있습니다. 그러나 원래 인스턴스는 더 오래있을 수 있었으므로 평균적으로 수집하는 데 약간 더 비쌉니다 (*). 원본 인스턴스가 새로운 동일한 인스턴스로 대체되는 대신 유지되는 경우 성능이 향상 될 수 있습니다.

(*) 새 값은 대개 방금 할당되었으므로 속성을 설정 한 후에 재사용하지 않습니다. 따라서 매우 자주 Gen0 객체로 수집하는 것이 효율적이지만 원래 값의 GC 생성은 알 수 없습니다.

이 추론이 맞으면 값 유형 속성 (int, double, DateTime, ...)에 대해 동일한 패턴을 보지 않을 것입니다.

물론 이것은 추측 일 뿐이며 완전히 잘못된 것일 수 있습니다.

5

속성이 변경된 경우에만 속성을 업데이트합니다. 이는 아마도 관련성이있을 수있는 참조 (및 모든 수반되는 메모리 관리)를 업데이트하는 것보다 비교가 더 저렴하다는 가정에 근거합니다.

+1

That와 문자열은 불필요한 사본을 많이 만드는 값 유형입니다. 항상 잘못된 것입니다 ... –

+2

@GrayWizardx : 필드를 설정해도 propertychange 알림이 발생하지 않습니다. @Jason D : 문자열은 값 유형이 아니지만 GC 비용과 관련이 있다고 판단 할 수 있습니다. 제 답변을 참조하십시오. – Joe

+0

이것은 완전히 정확하지는 않습니다. 'if' 블럭 안에서 속성 변경/변경된 통지를 보내기위한 호출이 없다면, 배킹 필드에 할당을 래핑하는 것으로 호출을 막을 수는 없습니다; 그들은'if'가 있는지 없는지 불리지 않고 있습니다. 이제는 일반적인 LINQ-to-SQL 생성 속성에 'OnPropertyChanging' 및'OnPropertyChanged ("PropertyName") '호출이 있으므로 이러한 알림을 사용하지 않도록 설정을 해제 한 것으로 의심됩니다. 발전기는 불필요한 경우에도 여전히 'if'블록을 포함시킴으로써 간단하게 유지했습니다. – jason

0

여기에 지속성이있는 것처럼 보입니다. _Property1이 변경 될 때 SQL UPDATE 쿼리를 생성하기 위해 리플렉션 (또는 포인트 컷 또는 기타)을 사용하는 경우 비교를 수행하는 것보다 필드를 업데이트하는 것이 훨씬 더 비쌉니다.

+0

반영 또는 포인트 컷으로 변수가 변경된 것을 어떻게 감지 할 수 있습니까? 나에게 링크를 줄 수 있니? 나는 빠른 검색을 수행하고 아무것도 찾지 못했다. (나는 C#과 구글에서 C# 키워드를 사용하여 더 많은 자바를 찾았다.) –

4

어디에서 볼 수 있습니까?

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

을 그리고 지금은 장치가 속성이 실제로 변경되지 않은 경우/알림을 변경 변경 전송 속성을 방지하는 것입니다 매우 분명하다 : 일반적인 LINQ - 투 - SQL 생성 된 속성은 다음과 같이.

이제

, 당신이 그들을 위해 다른 곳에 전화를 몸을 선언하지 않는 경우 있도록 그 방법은 (만약 그렇다면, 말 최종 어셈블리로 컴파일되지 않습니다에 OnProperty1ChangingOnProperty1Changedpartial 방법이라는 것을 밝혀, 당신은했다 리플렉터를보고 있으면이 전화를 볼 수 없습니다.) 그러나 SendPropertyChangingSendPropertyChanged은 컴파일 할 수없는 protected 메서드입니다.

그래서 코드 생성기에서 속성 변경/변경 알림을 내보낼 수 없도록하는 설정을 변경 했습니까?

+1

+1 - 생성 된 코드를 검사하지 않고이 설명 (속성 변경 알림이 비활성화되어 있고 'if '왼쪽에 제 위치에 블록) 더 가능성이 높습니다 GC의 마이크로 최적화 내가 내 대답에 대해 추측. – Joe

+0

@Joe : 예, 저는 이것이 주로 답이라고 생각합니다. LINQ-to-SQL 생성기가 때때로 해당 블록에 다른 코드 (예 : 변경되는 속성이 PK 또는 FK 인 경우)를 넣을 것이므로 설계 용이성을 위해 'if'블록이 아무렇게나 생성됩니다. (또는 의도되지 않았으며 이제는 "기능"입니다.) – jason

0

그것은 Heijlsberg의 오브젝트 파스칼 루트에서 온다 .... 적어도 그 볼랜드 델파이 VCL의 대부분이 ... 구현 방법)

관련 문제