디자인 검토 - IDispatcher 또는 Dispatcher 인스턴스 해결

Question

이상 MVVM 시나리오의 ViewModel에서 UI 변경 사항을 다시 UI 스레드로 알리는 ObservableCollection<T>을 확장하는 중입니다. 이를 위해 UI Dispatcher을 IOC까지 해결하고 궁극적으로 해결 된 Dispatcher 인스턴스를 내 사용자 정의 가능 유형 내에서 사용하려고합니다.

초안은 다음과 같습니다.

class SafeObservableCollection<T>: ObservableCollection<T> 
{ 
    public SafeObservableCollection(IDispatcher currentDispatcher)//maybe an instance of Dispatcher 
    { 
    //assign resolved dispatcher to a private member 
    } 
} 

가정 :(a) 하나 디스패처/UIThread 사용 WPF 애플리케이션. (나) 나는 어떤 편차의 떨어져 ObservableCollection에

질문의 최우선 기본 클래스 멤버에서 (BackgroundWorker에를 사용하여 APM/EPM)를 생각하고 있지 않다 : 당신이 디스패처 인스턴스를 해결하기 위해 더 나은 무엇을 제안 할 수있는 설명 된 코드를 따라 가면서? 가능한 디자인 결함을 찾아내는 데 도움을 줄 수 있습니까? 메모리 누수, 교착 상태 또는 간과 한 것 등. 이 방법을 사용하기로 결정한 경우 Dispatcher 인스턴스의 수명은 얼마일까요?

Answer 1

.NET 4.5를 사용하는 경우 새 차량을 발명해서 기존 기능을 사용할 수 없습니다.

//Creates the lock object somewhere 
private static object _lock = new object(); 

... 

//Enable the cross acces to this collection elsewhere 
BindingOperations.EnableCollectionSynchronization(_persons, _lock); 

이제 모든 스레드에서 _persons에 액세스 할 수 있습니다.

또한 스레드로부터 안전하게 관찰 할 수있는 WPFExtensions가 있습니다. http://wpfextensions.codeplex.com/

Answer 2

IDispatcher이 조롱 당할 수 있기 때문에 단위 테스트 가능으로 만들려는 것으로 가정합니다. 그렇지 않다면 Application.Current.Dispatcher을 사용하여 주 스레드로 다시 호출 할 수 있습니다.

Application.Current.Dispatcher을 감싸는 콘크리트로 해석되는 IDispatcher을 주입하면 메모리 누수, 교착 상태 등과 같은 문제가 없어야하며 쉽게 테스트/테스트가 가능합니다.

난 그냥 당신의 SafeObservableCollection 클래스의 IDispatcher에 대한 참조를 떠나 추천 할 것입니다, 당신은 mockability의 이점을 잃게됩니다 이후되지는 UI 스레드 Dispatcher 자체에 대한 직접 참조를받을 수 있습니다. IDispatcher에 Dispatcher 함수가 필요합니다.

평생 Dispatcher 래퍼의 인스턴스 중 하나가 SafeObservableCollection 일 때 좋지만, 추가 편집증 환자라면 IoC에서 문제없이 싱글 톤으로 해결할 수 있습니다.