"활성 개체"모음이 있습니다. 즉, 사전에 자신을 업데이트해야하는 개체입니다. 차례로 이러한 개체는 WPF 기반 GUI를 업데이트하는 데 사용해야합니다.WPF 및 활성 개체
이전에는 각 개체에 자체 스레드가 포함되어 있었지만 잘 정의 된 수명주기가있는 유한 개수의 개체로 작업 할 때만 의미가 있습니다. 이제는 양식에 필요할 때만 존재하는 객체를 사용하므로 수명주기가 예측할 수 없습니다. 또한 데이터베이스와 웹 서비스 호출을 모두하는 수십 개의 객체를 가질 수 있습니다.
업데이트 간격은 1 초이지만 시간 초과로 인해 최대 30 초가 걸릴 수 있습니다.
그래서 어떤 디자인을 권하고 싶습니까?
저는 전문가는 아니지만 변경된시기를 나타내는 이벤트를 발생 시켰습니다. GUI는 이벤트를 수신 할 때마다 (데이터 바인딩 및 INotifyPropertyChanged를 사용할 때) 쉽게 필요한 부분을 새로 고칠 수 있습니다.
간단합니다. 어려운 부분은 처음에 사용자가 새로 고침 버튼을 누르지 않아도 자신을 업데이트 할시기를 물체에 알려주는 것입니다. –
아마도 귀하의 질문을 이해할 수 없습니다. 각 객체가 자체 새로 고침을 처리하지 않습니까? 각 객체는 고유 한 타이머 및 시간 초과를 가질 수 있습니다. 그런 다음 개체가보고 할 가치가있는 이벤트를 감지 할 때마다 GUI에 알립니다. –
아마도 가능한 일종의 데이터 버스를 일반화하려고 할 것입니다. 그리고 개체가 '활성'일 때 업데이트 할 개체 목록에 자신을 추가하게하십시오. 개체별로 데이터베이스를 지원한다면이 패턴을 사용하는 것이 좋습니다. 각 개체 당 하나의 쿼리를 수행하는 대신 여러 쿼리를 집계 할 수 있습니다.
특정 개체에 대한 청취자가 없으면 별다른 문제가 발생하지 않습니다.
코어 업데이터 코드는 하나의 타이머 (또는 여러 항목 또는 적절한 항목)를 사용하여 업데이트를받을시기를 결정할 수 있습니다. 이것을 더 많은 데이터 흐름으로하고 '상태 업데이트'가 적어 질수록 결국 많은 정신병이 줄어들 것입니다.
그것은 데이터 객체의 캡슐화를 깨뜨린 것이지만 지금까지는 가장 좋은 방법이라고 생각합니다. –
장기간에 해결하기가 매우 어려울 수있는 높은 수준의 연결을 생성하는 경향이 있으므로 지속성 코드가있는 '데이터'(일반적으로 도메인 객체)를 캡슐화하는 것이 좋지는 않습니다. 그러나 그 커플 링을 정당화해야하는 타당한 이유가 있습니다. – kyoryu
활성 개체의 전체 또는 그룹에 대해 하나의 디스패처 (스케줄러)를 사용할 수 있습니다. Dispatcher는 먼저 우선 순위가 높은 타스크를 처리 한 다음 우선 순위가 높은 타스크를 처리 할 수 있습니다. 장기 실행 활성 객체에 대한 내용은 article 코드를 통해 확인할 수 있습니다. 추가로 하프 싱크/하프 비동기 패턴을 살펴 보는 것이 좋습니다. 질문이 있으시면 환영합니다.
하프 싱크/하프 비동기 패턴이란 무엇입니까? –
이 문서를 읽는 것이 더 좋습니다. www.cs.wustl.edu/~schmidt/PDF/PLoP-95.pdf. 조만간 우리는 자신의 작업 (동기 작업 또는 사용자 프로세스)과 비동기 적으로 실행되는 일부 외부 작업 (낮은 하위 이벤트 또는 다른 하위 시스템의 호출)을 실행하는 활성 객체를 갖게됩니다. – garik
개체를 업데이트하려는 이벤트는 무엇입니까? – Zied
기본적으로 어떤 형식의 타이머에는 외부 이벤트가 연결되지 않습니다. –