WWF: za i przeciw

Znalezione w internetach, nie są to moje opinie lub doświadczenia:

+ gdy chcemy zaprogramować proces, który często się zmienia;
+ mniejsze zużycie pamięci przy procesach, które mają długie czasy przestojów (oczekiwanie np na akceptację szefa, czyli dni lub tygodnie), ponieważ dane po odpowiedniej konfiguracji mogą być zapisywane w bazie danych zamiast w pamięci ulotnej (w razie awarii nie ma problemu z odzyskaniem adnych, stanu);
+ “graficznie” widać strukturę kodu (dostępny również document outline);

Outline View in Workflow Designer
Source: msdn.microsoft.com

+ udostępnia aktywności i kontrolę logiki w jaki sposób aplikacja przechodzi z jednego stanu do drugiego (dzięki temu można WWF wykorzystać do łatwej kontroli stanów takiej maszyny);

Completed State Machine Workflow
Source: msdn.microsoft.com

+ drag&drop activities;
+ można pisać własne kontrolki (podobne do UserControl)
+ workflow można wyeksponować na zewnątrz za pomocą WCF;
+ łatwość unit-testowania (dla każdej oddzielnej aktywności piszemy oddzielne testy, wiadomo do czego je pisać, łatwiej testować);
+ dzięki wizualnemu przedstawieniu “kodu”, “przejść” itd łatwiej to zobrazować użytkownikowi, analitykowi, innemu developerowi czy sponsorowi projektu, dzięki temu łatwiej jest zaprojektować  i napisać aplikację poprzez eliminowanie niektórych kroków (przygotowanie opisów dla użytkownika czy sponsora);

– podobno bardziej pamięcioziorne w stosunku do czystego kodu;
– problem ze wsteczną zgodnością (podobno rozwiązane od .NET 4,5);
– konieczność nauki nowej technologii;
– niedostępne dla .NET Core;
– trudności z debugowaniem (możliwe ale bardziej uciążliwe w stosunku do czystego kodu);
– problem z utrzymaniem kodu;
– ograniczona liczba dostępnych aktywności (można pisać swoje ale znów wymaga to nauki nowej technologii);
– duże zużycie pamięci (kilka aplikacji WF i serwer dyszy);
– WCF XAML bez interface’ów(?) – nie wiem o co chodzi;
– trudno znaleźć w miarę aktualną dokumentację, artykuły czy posty na temat technologii (młodsze niż rok);
– kod generowany przez WF jest brzydki;
– może spowodować wysypanie aplikacji w takim stanie, że nie będzie można normalnie jej przywrócić do pracy;
– “The only time I could ever conceive of using WF is if I wanted to host the designer for an end-user and probably not even then.

Trust me, nothing will ever be as straightforward, powerful, or flexible as the code that you write to do exactly what you need it to do. Stay away from WF.”

– nie zapewnia wystarczająco możliwości, łatwości stosowania i produktywności aby sensownie uzasadnić jego użycie;
– będziesz żałował, że się za to zabrałeś 🙂

 

Comments

(0 Comments)

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *