development

Windows Workflow Foundation을 언제 사용해야합니까?

big-blog 2020. 6. 9. 07:47
반응형

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


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

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


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

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

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

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


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

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

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

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

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


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


일반적으로 지속성 및 추적 기능 (필자의 의견으로는 주요 기능)이 필요하지 않은 경우 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 서비스가 인터페이스의 모든 것을 구현했는지 확인할 수 없습니다. 인터페이스를 정의 할 필요조차 없습니다. (내가 아는 한...)

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

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


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

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


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


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


I would use it in any environment where I need to work with workflow, however when using it in conjuction with K2 or even SharePoint 2007 the power of the platform is truly useful. When developing business applications with BI specialist the use of the platform is recommended and this would normally only be relevant to streamline and improve business processes.

For the record WF was developed in conjunction with K2's development team and the new K2 Blackpearl is built on top of WF, so is MOSS 2007 and WSS 3.0's workflow engines.


When you don't want to manually write all those codes to maintain the visual interface, tracking and persistence, it's a wise choice to vote for WF.


I have been using Windows workflow for months now to develop custom activities and a re-hosted designer that non-developers can use to build workflows. WF is very powerful but it is only as good as the custom activities that are built by developers. When it comes down to it, a developer would have to look over workflows built by non-developers to test and debug but from the point they can create draft workflows- that is fantastic.

Furthermore, in cases where you have long running processes WF is a good tech stack to use when you need to update processes dynamically - without having to reinstall/download or do anything, just add the new XAML files to a directory and your architecture should be set up with versioning to scrap the old one and use the new one.

참고URL : https://stackoverflow.com/questions/104099/when-to-use-windows-workflow-foundation

반응형