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

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?

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.

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. :)

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 .

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...)

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.

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.

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.

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.

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.

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.

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.