사용자 정의 이벤트 데이터 클래스 대신 DataEventArgs <TData>을 사용하는 것이 좋습니다.

Question

.Net 이벤트 "패턴"규칙을 위반하는 이벤트 선언에서 사용자 정의 EventArgs 상속 클래스를 선언하고 사용하는 대신 일반 DataEventArgs<TData> 클래스를 사용하고 있습니까? 또는 어떤 상황에서는 나쁜 습관을 고려한 것입니까?

는 (그것은 당신에게 전송되는 데이터의 유형을 보여줍니다 있지만 이벤트 인수를 이름의 명명 규칙은, DataEventArgs<TData> 이벤트 이름을 생략 사용. 이벤트 이름을 사용하고 접미사 "EventArgs입니다"를 추가하는 것입니다.)

TData에 사용하는 클래스를 수정할 수 없다면 일반 DataEventArgs 클래스가 다른 속성 추가와 같이 확장을 위해 일종의 폐쇄라고 주장 할 수 있습니다.

---

긴 설명 :

나는 표준 이벤트 "패턴"대회가 thusly 히 일반 이벤트 핸들러 대리자를 사용하여 선언하는 것을 이해 일부 데이터를 포함하는 표준 대의원 이벤트를 선언 할 때 :

public event EventHandler<SomethingHappendEventArgs> SomethingHappend; 

SomethingHappendEventArgs이 라인을 따라 무언가로 선언 된 경우

public class SomethingHappendEventArgs : EventArgs 
{ 
    public SomeDataType Value { get; private set; } 
    public SomethingHappendEventArgs(SomeDataType data) 
    { 
     this.Value = data; 
    } 
} 

주위를 둘러 보았을 때 Microsoft.Practices.Prism.Events를 비롯한 일반 DataEventArgs 클래스를 제공하는 여러 Microsoft 네임 스페이스가 있음을 발견했습니다. 그러나 SomethingHappendEventArgs와 같은 사용자 지정 이벤트 데이터 클래스 대신 해당 이벤트를 사용하는 경우 권장 사항이나 규칙을 찾을 수 없습니다.

그래서, 내가 이벤트 데이터에 포함 할 데이터의 하나 조각이 오히려이 같은 이벤트를 선언하는 것보다, SomethingHappendEventArgs처럼, 사용자 정의 이벤트 데이터 클래스를 사용해야하는 어떤 이유가,하는 것이어야한다?

public class DataEventArgs<TData> : EventArgs 
{ 
    public TData Value { get; private set; } 
    public DataEventArgs(TData value) 
    { 
     this.Value = value; 
    } 
} 

Answer 1

비 공개 이벤트에 대한 일반적인 EventArgs입니다 서브 클래스를 사용하지 않는 작은 이유가있다 : 일반 DataEventArgs 이런 식으로 뭔가를 선언 할 수

public event EventHandler<DataEventArgs<SomeDataType>> SomethingHappend; 

. 그러나 공개 API의 일부인 이벤트의 경우 이전 버전과의 호환성 문제로 인해 다소 까다로워집니다. 공개적으로 사용되는 이벤트의 경우, 이벤트 별 EventArgs 서브 클래스를 작성하면 API 사용자에게 영향을주지 않고 구성원을 추가 할 수있는 유연성을 얻을 수 있습니다.

공개 API의 일부가 아닌 이벤트의 경우 일반 하위 클래스가 더 이상 적합하지 않기 때문에 EventArgs 하위 클래스가 특정 이벤트에 대해 변경된 경우 여전히 약간의 재 작업이 필요합니다. 그러나 이것은 대개 상당히 적어야하며 컴파일러는 (명시 적 또는 익명 처리기 메서드 사용 여부에 관계없이) 모든 문제를 파악해야합니다. 분명히, 초기 개발 노력과 잠재적 인 변경 노력 사이에는 트레이드 오프가 존재할 것입니다. 나는 내부 이벤트에 일반적인 EventArgs를 사용하는데, 이것은 좋은 적응력을 가지고 있습니다. 해제.