Kiedy używać Windows Workflow Foundation? [Zamknięte]

154

Niektóre rzeczy są łatwiejsze do wykonania ręcznie (kod), ale niektóre są łatwiejsze dzięki WF. Wygląda na to, że WF można wykorzystać do stworzenia (prawie) dowolnego algorytmu. Więc (teoretycznie) mogę zrobić całą swoją logikę w WF, ale prawdopodobnie jest to zły pomysł, aby robić to dla wszystkich projektów.

W jakich sytuacjach warto korzystać z WF, a kiedy będzie to trudniejsze, niż powinno? Jakie są zalety i wady / koszt WF vs. kodowanie ręczne?

Sumrak
źródło
3
Wydaje się, że warto zauważyć, że został całkowicie przepisany na wydanie 4.0, które wyszło po tych odpowiedziach.
sclarson

Odpowiedzi:

125

Możesz potrzebować WF tylko wtedy, gdy spełniony jest którykolwiek z poniższych warunków:

  1. Masz długotrwały proces.
  2. Masz proces, który często się zmienia.
  3. Chcesz wizualnego modelu procesu.

Aby uzyskać więcej informacji, zobacz post Paula Andrew: Do czego używać Windows Workflow Foundation?

Proszę nie mylić ani nie odnosić WF do żadnego rodzaju programowania wizualnego. Jest to złe i może prowadzić do bardzo złych decyzji dotyczących architektury / projektu.

Panos
źródło
4
Jaka jest jednostka miary dla długotrwałego procesu?
ivorykoder
5
@ivorykoder "przetwarza" (naprawdę przepływy pracy ), które mogą przetrwać ponowne uruchomienie serwera, na którym się znajduje.
homaryzm
Gdybym miał wymagania, które spełniały tylko 1. miejsce, nie wystarczyłoby mi to na wybór WF. Jednak gdyby wymagania obejmowały # 2 i / lub # 3, byłby to znacznie mocniejszy argument za użyciem WF.
Mick
12
Nie mogę się oprzeć: możesz potrzebować WF tylko wtedy, gdy spełniony jest którykolwiek z następujących warunków: fałsz.
Ronnie Overby
84

Nigdy. Prawdopodobnie będziesz tego żałować:

  • Stroma krzywa uczenia się
  • Trudne do debugowania
  • Trudne do utrzymania
  • Nie zapewnia wystarczającej mocy, elastyczności ani produktywności, aby uzasadnić jego użycie
  • Może i spowoduje uszkodzenie stanu aplikacji, którego nie można odzyskać

Jedyny moment, w którym mógłbym sobie wyobrazić użycie WF, to gdybym chciał hostować projektanta dla użytkownika końcowego, a prawdopodobnie nawet wtedy.

Zaufaj mi, nic nigdy nie będzie tak proste, wydajne ani elastyczne jak kod, który piszesz, aby robić dokładnie to, czego potrzebujesz. Trzymaj się z dala od WF.

Oczywiście to tylko moja opinia, ale myślę, że jest cholernie dobra. :)

Ronnie Overby
źródło
27
-1 szanuję twoją opinię na ten temat, ale byłbym bardzo wdzięczny za profesjonalne wyjaśnienie powodu. Nie widzę, jak taka odpowiedź może komukolwiek pomóc
danfromisrael
9
Napisałem tę odpowiedź w dniu, w którym byłem zły na WF4. Zaktualizuję odpowiedź o napotkane problemy.
Ronnie Overby,
5
W połowie ukończony projekt odziedziczyliśmy od konsultanta, który wykorzystywał WF jako podstawę. Był podatny na błędy, zepsute przepływy pracy, których nie można uruchomić ponownie, archaiczny system wersjonowania, który wymaga całkowitego duplikowania przepływu pracy dla wszelkich drobnych zmian, przerażająco wygenerowany kod i tak delikatny, że trzeba sobie z tym radzić w dziecięcych rękawiczkach . Po 6 miesiącach żółtych ekranów śmierci wyrzuciliśmy cały WF i zamiast tego użyliśmy xml. Najlepsza decyzja, jaką kiedykolwiek podjęliśmy.
Kevin DeVoe
10
Wyrażenie: „Nie zapewnia wystarczającej mocy, elastyczności lub produktywności, aby uzasadnić jego użycie”, mówi mi wystarczająco dużo. Dziękuję za to.
David Tansey
1
Hejterzy muszą wyjaśnić swoją nienawiść.
Ronnie Overby,
46

Kod wygenerowany przez WF jest nieprzyjemny. Wartość, jaką wnosi WF, polega na wizualnej reprezentacji systemu, chociaż jeszcze nie widziałem niczego (6-7 projektów w pracy z WF, w które byłem zaangażowany), w którym nie wolałbym prostszego projektu zakodowanego ręcznie .

Craigb
źródło
40

Ogólnie rzecz biorąc, jeśli nie potrzebujesz funkcji trwałości i śledzenia (które moim zdaniem są głównymi cechami), nie powinieneś używać Workflow Foundation.

Oto zalety i wady Workflow Foundation, które zebrałem z mojego doświadczenia:

Zalety

  • Trwałość: Jeśli zamierzasz mieć wiele długotrwałych procesów (pomyśl o dniach, tygodniach, miesiącach), przepływy pracy są do tego idealne. Bezczynne wystąpienia przepływu pracy są utrwalane w bazie danych, więc nie zużywają pamięci.
  • Śledzenie: WF zapewnia mechanizm śledzenia każdego działania wykonywanego w przepływie pracy
  • * Projektant wizualny: umieściłem to jako *, ponieważ myślę, że jest to przydatne tylko do celów marketingowych. Jako programista wolę pisać kod, niż wizualnie łączyć elementy. A kiedy masz pracownika niebędącego programistą, który tworzy przepływy pracy, często kończy się to ogromnym, zagmatwanym bałaganem.

Niedogodności

  • Model programowania: masz naprawdę ograniczone funkcje programistyczne. Pomyśl o wszystkich wspaniałych funkcjach, które masz w C #, a potem zapomnij o nich. Prosta jedna lub dwie instrukcje linii w C # stają się dość dużymi działaniami blokowymi. Jest to szczególnie uciążliwe w przypadku walidacji danych wejściowych. Powiedziawszy to, jeśli naprawdę starasz się zachować tylko logikę wysokiego poziomu w przepływach pracy i wszystko inne w C #, może to nie być problem.
  • Wydajność: przepływy pracy zużywają dużą ilość pamięci. Jeśli wdrażasz wiele przepływów pracy na serwerze, upewnij się, że masz mnóstwo pamięci. Należy również pamiętać, że przepływy pracy są znacznie wolniejsze niż normalny kod C #.
  • Stroma krzywa uczenia się, trudna do debugowania: jak wspomniano powyżej. Będziesz spędzać dużo czasu, zastanawiając się, jak sprawić, by rzeczy działały i znaleźć najlepszy sposób na zrobienie czegoś.
  • Niezgodność wersji przepływu pracy: jeśli wdrażasz przepływ pracy z trwałością i musisz wprowadzić aktualizacje przepływu pracy, stare wystąpienia przepływu pracy nie są już zgodne. Podobno zostało to naprawione w .NET 4.5.
  • Musisz używać wyrażeń VB (.NET 4.5 pozwala na wyrażenia C #).
  • Brak elastyczności: jeśli potrzebujesz jakiejś specjalnej lub specyficznej funkcjonalności, której nie zapewnia Workflow Foundation, przygotuj się na wiele bólu. W niektórych przypadkach może to nawet nie być możliwe. Kto wie, dopóki nie spróbujesz? Istnieje duże ryzyko.
  • Usługi WCF XAML bez interfejsów: zwykle w przypadku usług WCF programujesz w oparciu o interfejs. W przypadku usług WCF XAML nie można zagwarantować, że usługa WCF XAML zaimplementowała wszystko w interfejsie. Nie musisz nawet definiować interfejsu. (z tego co wiem...)
Mas
źródło
7
Większość twoich wad jest po prostu nieprawda, być może nie znasz wystarczająco WF. WF jest bardzo elastyczny. Umożliwia pisanie działań niestandardowych (działań w kodzie), których można ponownie użyć w dowolnym scenariuszu. Do Ciebie należy pisanie działań wielokrotnego użytku. Wyobraź sobie, że możesz udostępnić konsultantom biznesowym GUI (aplikację WPF z hostem projektanta przepływu pracy) wraz z zestawem narzędzi do działań. Teraz mogą zmieniać i przeorganizować logikę biznesową w swoich potrzebach i nie wymagają programistów, a nawet kompilowania nowej aplikacji.
Sven
3
Teraz wyobraź sobie, że konsultanci biznesowi muszą używać Twojego projektanta na własnym serwerze, ale bez technologii Intellisense! Albo zrezygnuj samodzielnie, albo musisz użyć programu Visual Studio. Myślę również, że konsultantom biznesowym trudno będzie nawet zrozumieć niektóre pojęcia, takie jak odszkodowanie, anulowanie, obsługa wyjątków. Również każda logika, która jest zdalnie złożona, spowoduje gigantyczny przepływ pracy, który stanie się nie do utrzymania (och, a będziesz potrzebować mnóstwo pamięci RAM, aby edytować takie przepływy pracy). Masz jednak rację, dzięki starannie wykonanym niestandardowym działaniom zapewniają sporą elastyczność.
Mas
27

Głównym powodem, dla którego znalazłem zastosowanie podstawy przepływu pracy, jest to, jak bardzo wyciąga ona cię z pudełka pod względem śledzenia i trwałości. Bardzo łatwo jest skonfigurować i uruchomić usługę trwałości, która zapewnia niezawodność i rozkład obciążenia między wieloma instancjami i hostami.

Z drugiej strony, podobnie jak aplikacje formularzy, wzorce kodu, do których popycha Cię projektant przepływu pracy, są złe. Możesz jednak uniknąć problemów, nie pisząc kodu w przepływie pracy i delegując całą pracę do innych klas, które mogą być organizowane i testowane jednostkowo z większą wdziękiem niż przepływ pracy. Wtedy otrzymujesz fajny wizualny aspekt projektanta bez okruchów kodu spaghetti.

Tegan Mulholland
źródło
11

Osobiście nie jestem sprzedawany na WF. Jego użyteczność nie była dla mnie tak oczywista, jak inne nowe technologie MS, takie jak WPF czy WCF.

Myślę, że WF będzie w przyszłości intensywnie używany w aplikacjach biznesowych, ale nie planuję go używać, ponieważ nie wydaje mi się, aby był to odpowiednie narzędzie do pracy w moich projektach.

Obrabować
źródło
7

Firma, dla której obecnie pracuję, skonfigurowała platformę Windows Workflow Foundation (WF) i powody, dla których zdecydowali się jej użyć, były spowodowane tym, że reguły często się zmieniały, co zmusiłoby ich do ponownej kompilacji różnych bibliotek dll itp., A więc ich rozwiązania polegało na umieszczeniu reguł w DB i wywołaniu ich stamtąd. W ten sposób mogli zmienić zasady i nie musieli ponownie kompilować i redystrybuować bibliotek dll itp.

rae1
źródło
21
Szkoda, że ​​zwykłe usługi internetowe i aplikacje nie mają plików .config, nie mogą czytać baz danych, XML ani plików lokalnych zawierających reguły bez ponownej kompilacji. Och, czekaj ...
Dour High Arch
6

Przepływy pracy Windows uwodzą niekodujących menedżerów IT, BA i tym podobnych, podobnie jak jego kuzyn BizTalk, ale w praktyce testowanie jednostkowe, debugowanie i pokrycie kodu to tylko trzy z wielu pułapek. Możesz pokonać niektóre z nich, ale musisz dużo zainwestować, aby to osiągnąć, podczas gdy w przypadku zwykłego kodu po prostu to uzyskasz. Jeśli naprawdę masz długoterminowe wymagania, prawdopodobnie potrzebujesz czegoś bardziej wyrafinowanego. Słyszałem argument o możliwości upuszczania nowych plików xaml do produkcji bez ponownej kompilacji bibliotek dll, ale szczerze mówiąc, czas, który będą zużywać przepływy pracy, można lepiej wykorzystać do ulepszenia ciągłej integracji do punktu, w którym skompilowane wdrożenia nie stanowią problemu.

Owain Glyndŵr
źródło
3

Używałbym go w każdym środowisku, w którym potrzebuję pracować z przepływem pracy, jednak w połączeniu z K2, a nawet SharePoint 2007 moc platformy jest naprawdę przydatna. Podczas tworzenia aplikacji biznesowych ze specjalistami BI zaleca się korzystanie z platformy, co zwykle ma znaczenie tylko dla usprawnienia i usprawnienia procesów biznesowych.

Dla przypomnienia, WF został opracowany we współpracy z zespołem programistów K2, a nowy K2 Blackpearl jest oparty na WF, podobnie jak silniki przepływu pracy MOSS 2007 i WSS 3.0.

BinaryMisfit
źródło
2

Jeśli nie chcesz ręcznie pisać wszystkich tych kodów, aby zachować interfejs wizualny, śledzenie i trwałość, mądrym wyborem jest głosowanie na WF.

sparksustc
źródło
1

Od miesięcy używam przepływu pracy systemu Windows do opracowywania niestandardowych działań i ponownie hostowanego projektanta, którego osoby niebędące programistami mogą używać do tworzenia przepływów pracy. WF jest bardzo potężny, ale jest tak dobry, jak niestandardowe działania tworzone przez programistów. Jeśli chodzi o to, programista musiałby przejrzeć przepływy pracy utworzone przez osoby niebędące programistami w celu testowania i debugowania, ale od momentu, w którym mogą tworzyć robocze przepływy pracy - to fantastyczne.

Co więcej, w przypadkach, w których masz długo działające procesy, WF jest dobrym stosem technicznym do użycia, gdy musisz dynamicznie aktualizować procesy - bez konieczności ponownej instalacji / pobierania lub wykonywania czegokolwiek, po prostu dodaj nowe pliki XAML do katalogu, a Twoja architektura powinna być skonfiguruj z wersjonowaniem, aby odrzucić stary i użyć nowego.

JohnChris
źródło