1
이 질문에 성능과 관련하여 주요 관심사로 질문하고 있습니다. 그러나 나는 두 가지 접근법에 대한 다른 가능한 장단점을 알고 싶다.속성 변수를 직접 액세스하여 멤버 변수에 액세스
질문은 다음과 같습니다. 속성이 일리노이의 메서드로 변환 되었기 때문에 필드를 클래스에 직접 액세스하는 대신 속성을 호출하면 성능이 크게 저하 될 수 있습니까?
전적으로 IDataReader에서 "도메인 엔터티를 구성하는"변환 클래스 (PersonalizationConstructor)를 설계하고 있습니다.
나는이 클래스 (PersonalizationConstructor)의 생성자에서 IDataReader를 받아들이고 IDataReader 레코드 집합에서 데이터를 반환하도록 가상 속성을 보호하려고합니다. like :
protected virtual string ProductFilterCriteria
{
get;
set;
}
이 구현을 위해 하나의 클래스에 15 개 이상의 속성이있을 수 있습니다. 이렇게하면 레코드 집합에서 액세스하기 전에 레코드 집합에 "XXX"필드가 있는지 확인하기 위해 속성을 재정의 할 수 있습니다 (모든 개체에 대한 기본 구현을 원하지 않습니다).
위의 경우를 구현하기 위해 클래스에 15 개 이상의 가상 속성을 갖는 것이 좋습니까?
IDataReader에 집중하지 마십시오. 내 주요 관심사입니다 : 속성 IL의 방법으로 변환됩니다
때문에, 성능 처벌 중요한있을 수 속성 대신 (클래스 내에서) 직접 필드 접근이라고하면?
에게 는 나는이 같은 낳게 될 것이다:
class MainSite
{
protected virtual string ProductFilterCriteria
{
get
{
return _source["ProductFilterCriteria"];
}
}
protected virtual string Abc
{
get
{
return _source["Abc"];
}
}
protected virtual string Def
{
get
{
return _source["Def"];
}
}
..... many properties
}
class VirtualSite : MainSite
{
protected override string ProductFilterCriteria
{
get
{
return null;
}
}
}
이 경우는 가상 속성이므로 속성을 봉인하는 유형으로 알려져있는 경우를 제외하고는 최적화 할 수 없습니다. –
@ 존 : 감사합니다, 당신은 절대적으로 옳습니다. 그러나 그때조차도, 부동산에서 현장으로 옮겨가는 것에서의 성과 이득은 거의 모든 시나리오에서 무시할 수 있습니다. – Abel