Windows Workflow Foundation을 언제 사용해야합니까? [닫은]

154

손으로 직접 구현하는 것이 더 쉬운 것도 있지만 (코드) 일부는 WF를 통해 더 쉽게 구현할 수 있습니다. WF를 사용하여 거의 모든 종류의 알고리즘을 만들 수 있습니다. 따라서 (이론적으로) WF에서 모든 논리를 수행 할 수는 있지만 모든 프로젝트 에서이 작업을 수행하는 것은 좋지 않습니다.

어떤 상황에서 WF를 사용하는 것이 좋으며 언제보다 힘들게해야합니까? WF 대 코딩의 장단점은 무엇입니까?

.net workflow workflow-foundation

— 수악
소스

3

이 답변 후에 나온 4.0 릴리스에 대해 완전히 다시 작성된 것은 주목할 가치가 있습니다.

— sclarson 2016 년

125

다음 중 하나에 해당하는 경우에만 WF가 필요할 수 있습니다.

오래 실행되는 프로세스가 있습니다.
자주 변경되는 프로세스가 있습니다.
프로세스의 시각적 모델이 필요합니다.

자세한 내용은 Paul Andrew의 게시물 : Windows Workflow Foundation 사용 대상을 참조하십시오 .

WF를 어떤 종류의 시각적 프로그래밍과 혼동하거나 연관시키지 마십시오. 잘못되어 매우 잘못된 아키텍처 / 디자인 결정으로 이어질 수 있습니다.

— 파 노스
소스

4

장기 실행 프로세스를위한 측정 단위는 무엇입니까?

— ivorykoder

5

@ivorykoder "프로세스"(실제로 워크 플로 )는 호스트 서버를 다시 시작해도 살아남을 수 있습니다.

— 랍스터주의

# 1 만 만족하는 요구 사항이 있다면 WF를 선택하기에 충분하지 않습니다. 그러나 요구 사항에 # 2 및 / 또는 # 3이 포함되어 있으면 WF를 사용하는 것이 훨씬 더 강력합니다.

— Mick

12

나는 저항 할 수 없다 : 다음 중 하나에 해당하는 경우에만 WF가 필요할 수있다 : 거짓.

— Ronnie Overby

84

못. 당신은 아마 그것을 후회할 것입니다 :

가파른 학습 곡선
디버깅하기 어려움
유지하기 어려움
사용을 정당화하기에 충분한 전력, 유연성 또는 생산성 향상을 제공하지 않습니다
복구 할 수없는 응용 프로그램 상태를 손상시킬 수 있습니다

WF 사용을 생각할 수있는 유일한 시간은 최종 사용자를 위해 디자이너를 호스팅하고 싶을 때뿐입니다.

나를 믿으십시오. 필요한 작업을 수행하기 위해 작성한 코드만큼 간단하거나 강력하거나 유연하지 않습니다. WF에서 멀리 떨어지십시오.

물론 이것은 내 의견 일 뿐이지 만, 그것이 좋은 것이라고 생각합니다. :)

— 로니 오버 비
소스

27

-1 나는 이것에 대한 당신의 의견을 존중하지만 그 이유에 대한 전문적인 설명을 많이 할 것입니다. 나는 이런 종류의 답변이 어떤 사람에게 도움이되는지 알 수 없다

— danfromisrael

9

나는 WF4에 화가 났던 날 에이 답변을 썼습니다. 내가 직면 한 문제로 답변을 업데이트하겠습니다.

— Ronnie Overby

5

우리는 WF를 백본으로 사용하는 컨설턴트로부터 절반의 완성 된 프로젝트를 물려 받았습니다. 오류, 다시 시작할 수없는 손상된 워크 플로, 사소한 변경을 위해 워크 플로를 완전히 복제해야하는 구식 버전 관리 시스템, 끔찍한 코드 및 키즈 장갑으로 처리해야하는 섬세한 코드가 발생하기 쉽습니다. . 6 개월 동안 노란색으로 사망 한 후 WF 전체를 폐기하고 대신 xml을 사용했습니다. 우리가 한 최고의 결정.

— 케빈 DeVoe

10

문구 : "그것의 사용을 정당화하기에 충분한 전력, 유연성, 생산성 이득을 제공하지 않습니다" 나를 위해 충분히 충분했다. 고마워

— David Tansey

1

증오자는 증오를 설명해야합니다.

— Ronnie Overby

46

WF가 생성 한 코드가 불쾌합니다. WF가 제공하는 가치는 시스템을 시각적으로 표현한 것이지만, 더 간단한 수작업으로 코딩 된 프로젝트를 선호하지 않는 부분은 아직 보지 못했지만 .

— craigb
소스

40

일반적으로 지속성 및 추적 기능이 필요하지 않은 경우 (내 의견으로는 주요 기능 임) Workflow Foundation을 사용하지 않아야합니다.

내 경험에서 수집 한 Workflow Foundation의 장단점은 다음과 같습니다.

장점

지속성 : 장기간 실행되는 프로세스가 많을 경우 (일, 주, 개월) 워크 플로가 적합합니다. 유휴 워크 플로 인스턴스는 데이터베이스에 유지되므로 메모리를 사용하지 않습니다.
추적 : WF는 워크 플로에서 실행 된 각 활동을 추적하는 메커니즘을 제공합니다.
* 비주얼 디자이너 : 나는 이것을 마케팅 목적으로 만 유용하다고 생각하기 때문에 이것을 *로 넣었다. 개발자는 시각적으로 서로를 묶는 대신 코드를 작성하는 것을 선호합니다. 개발자가 아닌 제작 워크 플로를 사용하는 경우 종종 혼란스러운 혼란이 생깁니다.

단점

프로그래밍 모델 : 프로그래밍 기능에는 한계가 있습니다. C #의 모든 훌륭한 기능을 생각하고 잊어 버리십시오. C #에서 단순한 하나 또는 두 개의 라인 명령문은 상당히 큰 블록 활동이됩니다. 이것은 특히 입력 검증에 어려움이 있습니다. 그러나 워크 플로에서 높은 수준의 논리 만 유지하고 C #의 다른 모든 요소 만 유지하려면주의를 기울이면 문제가되지 않을 수 있습니다.
성능 : 워크 플로는 많은 양의 메모리를 사용합니다. 서버에 많은 워크 플로를 배포하는 경우 많은 메모리가 있는지 확인하십시오. 또한 워크 플로는 일반적인 C # 코드보다 훨씬 느립니다.
가파른 학습 곡선, 디버깅하기 어렵다 : 위에서 언급 한 바와 같이. 일을하는 방법을 알아 내고 무언가를하는 가장 좋은 방법을 알아내는 데 많은 시간을 할애해야합니다.
워크 플로 버전 비 호환성 : 지속성이있는 워크 플로를 배포하고 워크 플로를 업데이트해야하는 경우 이전 워크 플로 인스턴스는 더 이상 호환되지 않습니다. 아마도 이것은 .NET 4.5에서 수정되었습니다.
VB 표현식을 사용해야합니다 (.NET 4.5에서는 C # 표현식이 허용됨).
융통성 없음 : Workflow Foundation에서 제공하지 않는 특수한 기능이나 특정 기능이 필요한 경우 많은 어려움에 대비하십시오. 경우에 따라 불가능할 수도 있습니다. 시도 할 때까지 누가 알 겠어요? 여기에는 많은 위험이 있습니다.
인터페이스가없는 WCF XAML 서비스 : 일반적으로 WCF 서비스에서는 인터페이스에 대해 개발합니다. WCF XAML 서비스를 사용하면 WCF XAML 서비스가 인터페이스의 모든 것을 구현했는지 확인할 수 없습니다. 인터페이스를 정의 할 필요조차 없습니다. (내가 아는 한...)

— 마스
소스

7

대부분의 단점은 사실이 아니며 WF에 익숙하지 않을 수도 있습니다. WF는 매우 유연합니다. 모든 시나리오에서 재사용 할 수있는 사용자 정의 활동 (코드 활동)을 작성할 수 있습니다. 재사용 가능한 활동을 작성하는 것은 귀하의 책임입니다. 활동 도구 세트와 함께 비즈니스 컨설턴트에게 GUI (Workflow Designer Host가 포함 된 WPF 앱)를 제공 할 수 있다고 가정하십시오. 이제 필요에 따라 비즈니스 로직을 변경 및 재 배열 할 수 있으며 개발자가 필요하지 않으며 새 애플리케이션을 컴파일 할 수도 있습니다.

— Sven

3

이제 비즈니스 컨설턴트가 자체 호스팅 디자이너를 사용하지만 Intellisense없이 사용해야한다고 상상해보십시오! 자신의 롤 또는 Visual Studio를 사용해야합니다. 또한 비즈니스 컨설턴트는 보상, 취소, 예외 처리와 같은 일부 개념을 이해하기가 어려울 것으로 생각합니다. 또한 이벤트가 원격으로 복잡한 모든 논리는 유지 관리 할 수없는 거대한 워크 플로우를 초래합니다 (아, 이러한 워크 플로우를 편집하려면 많은 램이 필요합니다). 그러나 신중하게 제작 된 사용자 지정 활동을 통해 상당한 유연성을 얻을 수 있습니다.

— Mas

27

워크 플로 파운데이션을 사용하여 찾은 주요 이유는 추적 및 지속성 측면에서 얼마나 많은 이점을 제공하는지에 대한 것입니다. 지속성 서비스를 시작하고 실행하는 것은 매우 쉬워 여러 인스턴스와 호스트간에 안정성과로드 분산을 제공합니다.

반면, 양식 앱과 마찬가지로 워크 플로 디자이너가 사용자에게 제공하는 코드 패턴은 나쁩니다. 그러나 워크 플로에 코드를 작성하지 않고 모든 작업을 다른 클래스에 위임하여 문제를 피할 수 있습니다. 워크 플로보다 체계적으로 구성하고 단위 테스트를 수행 할 수 있습니다. 그런 다음 스파게티 코드를 숨기지 않고도 디자이너의 멋진 시각적 측면을 얻을 수 있습니다.

— 테간 멀홀랜드
소스

11

개인적으로 저는 WF에서 판매되지 않습니다. WPF 또는 WCF와 같은 다른 새로운 MS 기술만큼 유용하지 않았습니다.

WF는 향후 비즈니스 응용 프로그램에서 많이 사용될 것으로 생각하지만 프로젝트에 적합한 도구로 보이지 않기 때문에 사용할 계획이 없습니다.

— 롭
소스

7

현재 WF (Windows Workflow Foundation)를 설정하기 위해 노력하고있는 회사와 규칙을 자주 사용하는 이유는 규칙이 자주 변경되어 다양한 dll 등을 다시 컴파일해야하기 때문입니다. DB에 규칙을 배치하고 거기서부터 호출해야했습니다. 이런 식으로 규칙을 변경하고 dll 등을 다시 컴파일하고 재배포 할 필요가 없습니다.

— rae1
소스

21

너무 나쁜 일반 웹 서비스 및 응용 프로그램에는 .config 파일이 없으며 데이터베이스를 읽을 수 없으며 규칙을 포함하는 XML 또는 로컬 파일을 다시 컴파일하지 않고도 읽을 수 없습니다. 아 잠깐만 ...

— Dour High Arch

6

Windows Workflows는 사촌 BizTalk와 마찬가지로 비 코딩 IT 관리자, BA 등을 유혹하지만 실제로 단위 테스트, 디버깅 및 코드 적용 범위는 많은 함정 중 3 가지에 불과합니다. 당신은 그들 중 일부를 극복 할 수 있지만 그것을 달성하기 위해 많은 투자를 해야하는 반면 일반 코드를 사용하면 얻을 수 있습니다. 실제로 오래 실행되는 요구 사항이 있다면 더 정교한 것이 필요할 것입니다. dll을 다시 컴파일하지 않고 새로운 xaml 파일을 프로덕션에 드롭 할 수 있다는 주장을 들었지만 솔직히 Workflows가 소비하는 시간은 컴파일 된 배포가 문제가되지 않는 시점까지 Continuous Integration을 개선하는 데 더 잘 사용될 수 있습니다.

— 오 웨인 글 린드
소스

3

워크 플로로 작업해야하는 모든 환경에서 사용하지만 K2 또는 SharePoint 2007과 함께 사용할 경우 플랫폼의 성능이 정말 유용합니다. BI 전문가와 함께 비즈니스 응용 프로그램을 개발할 때는 플랫폼을 사용하는 것이 좋으며 이는 일반적으로 비즈니스 프로세스를 간소화하고 향상시키는 데만 관련이 있습니다.

기록을 위해 WF는 K2의 개발 팀과 함께 개발되었으며 새로운 K2 Blackpearl은 WF 위에 구축되었으며 MOSS 2007 및 WSS 3.0의 워크 플로 엔진도 마찬가지입니다.

— 이진 미스 핏
소스

2

시각적 인터페이스, 추적 및 지속성을 유지하기 위해 모든 코드를 수동으로 작성하지 않으려면 WF에 투표하는 것이 현명한 선택입니다.

— 스파크
소스

1

저는 몇 달 동안 Windows 워크 플로를 사용하여 개발자가 아닌 사용자가 워크 플로를 작성하는 데 사용할 수있는 사용자 지정 활동 및 다시 호스팅 된 디자이너를 개발했습니다. WF는 매우 강력하지만 개발자가 구축 한 사용자 지정 활동만큼 좋습니다. 문제가 발생하면 개발자는 개발자가 아닌 사람이 제작 한 워크 플로를 테스트하고 디버깅해야하지만 초안 워크 플로를 만들 수있는 시점에서 환상적인 워크 플로를 검토해야합니다.

또한 프로세스를 오래 실행하는 경우 WF는 프로세스를 동적으로 업데이트해야 할 때 다시 설치 / 다운로드하거나 아무것도하지 않고도 사용할 수있는 좋은 기술 스택입니다. 디렉토리에 새 XAML 파일을 추가하기 만하면됩니다. 이전 버전을 스크랩하고 새 버전을 사용하도록 버전 관리를 설정합니다.

— 존 크리스
소스