저는 직렬 통신을 통해 정교한 하드웨어를 제어 할 수있는 상당한 규모의 WPF 애플리케이션을 개발하는 데있어 중요한 방법입니다. 응용 프로그램 "스택"의 맨 아래에는 직렬 통신 계층 (.Net 'SerialPort'클래스 사용)이 있습니다. H/W 장치에 대한 읽기 및 쓰기는 비즈니스 로직 계층의 여러 영역에서 활용되는 시스템의 기본 부분으로 종종 복잡한 과학 계산 및 기타 논리가 산재 해 있습니다. 이러한 BLL 메서드는 차례대로 UI 계층 전체에서 호출됩니다.내 GUI 응용 프로그램에 대해 비동기 "all way"를 사용해야합니까?
현재 SerialPort 읽기 및 쓰기를 포함하여 비즈니스 논리 계층의 모든 것이 동기입니다. async/await을 사용하는 유일한 경우는 일반적으로 비즈니스 로직을 호출 할 때 UI 계층에 있습니다. 여기에 내가 e.g.:-, Task.Run()에
private async void SomeButtonClick(object sender, EventArgs e)
{
await Task.Run(() => _someBLLService.TurnPumpOn());
}
이 밀리 초 단위의 문제를 취하는 간단한 예제를 호출을 래핑 수 있습니다. 보다 복잡한 예제는 장기 실행 프로세스를 시작하는 것입니다 (위의 기술을 다시 사용). 이 비즈니스 로직 "서비스"는 몇 초 또는 몇 분 동안 실행되어 하드웨어에서 데이터를 수집하고이 시간 동안 다른 "제어"기능을 수행합니다. 주기적으로 pubsub 이벤트 수집기 프레임 워크를 통해 차트에 플로팅하기 위해 데이터를 다시 UI로 브로드 캐스팅합니다. 위의 기술은 잘 작동하므로 비즈니스 계층 프로세스가 진행되는 동안 UI가 응답 할 수 있습니다.
최근에는 시리얼 통신 코드 (예 : .ReadAsync 사용)로 시작하여 '비동기로 계속 진행'을 고려하고 있지만 시스템 전체에 영향을 미칩니다. 수십 개 (수백 개는 아니더라도)의 비즈니스 로직 메소드를 비동기 메소드로 리팩토링해야합니다 (UI 계층까지). 여기에 약간 위의 코드를 단순화 할 수있을 것입니다 :
private async void SomeButtonClick(object sender, EventArgs e)
{
await _someBLLService.TurnPumpOn();
}
내가, 내가 혜택이 정말 무엇인지 궁금하네요 큰 리팩토링 작업을 태클을 싫어하지 않아요 동안. Stephen Cleary와 같은 많은 사람들이 "async all way"솔루션을 주창하지만, 주 목적은 내 Task.Run() 기술이 이미 수행하는 장기 실행 BLL 프로세스를 호출 할 때 UI를 응답 성있게 유지하는 것입니다.
"async all way"는 "비동기 코드를 차단하지 마십시오"라고 말하는 또 다른 방법입니다. 이것은 한 방향으로 만 진행됩니다.UI 애플리케이션의 경우, 비동기의 가장 큰 장점은 응답 성입니다.'Task.Run 대기 '는 완벽하게 훌륭한 솔루션입니다. –