Porównanie między Stateless (w kodzie google) i Windows Workflow [zamknięty]

Question

Porównanie między Stateless (w kodzie google) i Windows Workflow [zamknięty]

Zaczynam myśleć, że powinienem porzucić Windows WF na rzecz czegoś prostszego. Nie muszę wstrzymywać wykonywania workflow przez dłuższy czas i przywracać je później. Chciałbym mieć prosty framework maszyny stanowej, który ma basic suspend / resume / abort (bez serializacji), jednak.

Ściągnąłem Stateless framework z Google Code i zamierzam zacząć z nim grać, ale chciałbym usłyszeć, co inni programiści. NET tam są zażywające.

EDIT Stateless wydaje się naprawdę prosty w implementacji, ale zastanawiam się, czy to właściwe dla maszyny cukierkowej. W automatyzacji zawsze czuję się skonfliktowany co do tego, jak powinny być używane maszyny państwowe. Chociaż używam terminu "maszyna stanowa", robię to luźno, ponieważ używam go bardziej jak SCHEMAT BLOKOWY. Zamiast używać stanów do reprezentowania bieżącego trybu maszyny, używam go do wykonywania funkcji. Więc w tym przypadku ze Stateless, faktycznie używałbym przejście z jednego stanu do następnego jako mechanizm wywoływania funkcji w kontrolerze mojej cukierkowej maszyny. Myśli?

32

.net c#state-machines workflow-foundation

Author: user7116, 2010-02-13

Source

1 answers

score 40 · Accepted Answer

Jak będę pracować nad tym, postaram się wymienić niektóre z rzeczy, które znajduję. Większość prawdopodobnie będzie nieco powierzchowna z punktu widzenia analizy (zwłaszcza, że jestem nowy w obu frameworkach), ale mam nadzieję, że komuś to pomoże.

Stateless

plusy

open source
składniowo zwięzły i łatwy do odczytania
całkiem dobre przykłady w mercurial repo na Google code
mogę przetłumaczyć mój diagram stanu UML na kod przy użyciu stateless bardzo szybko.
utrzymanie stanu jest bardzo proste -- z łatwością mogę dodawać i usuwać. Metody rozszerzeń pozwalają mi skonfigurować stany w osobnych liniach, aby móc komentować wyzwalacze lub akcje, których nie chcę używać.
przekazywanie danych do / Z maszyny stanowej jest łatwe i możesz to zrobić, jak chcesz w kodzie-behind.
podobnie maszyna stanowa może aktualizować GUI na wiele sposobów. W tej chwili modyfikuję dane za pomocą interfejsu, a następnie GUI używa timera do aktualizacji swoich elementów. Przydałby mi się też do tego pracownik tła.
właśnie zacząłem używać podstat do obsługi mojego GUI, który musi zarządzać różnymi stanami, takimi jak uruchomiony, wstrzymany, przerwany i bezczynny. Stan wstrzymany ma podstacje, ponieważ użytkownik może wstrzymać system na wiele sposobów, ale wyzwalacze wznowienia są specyficzne dla sposobu, w jaki zostały wstrzymane. Uwielbiam być w stanie zarządzać moim GUI włączanie / wyłączanie i podpowiedzi za pomocą lekka struktura maszyny stanowej.

Cons

brak wbudowanych mechanizmów wstrzymywania, wznawiania, przerywania
tylko jeden programista wspierający projekt. Otrzymałem jednak pomoc z problemem, na który ostatnio wpadłem.
możliwość niewłaściwego użycia, jeśli nie jesteś ostrożny. Przy pierwszej próbie nieprawidłowo zaimplementowałem Framework maszyny Państwowej. To działało świetnie przez miesiące, a potem w końcu umarł, gdy prowadził bardzo długotrwały proces. Odwraca się Na Zewnątrz powodowałem, że stan Obsługi się układał i miałem stan przepełnienia stosu.

Windows Workflow Foundation

plusy

graficzne podejście do projektowania workflow
podtrzymywanie, wstrzymywanie, wznawianie, przerywanie przepływów pracy
MS prawdopodobnie ma duży zespół programistów, którzy to wspierają
GUI ułatwia wyłączenie / ponowne włączenie działania

Cons

graficzne podejście do projektowania workflow ukrywa fakt, że jest to dość skomplikowane
aby użyć persistence i uzyskać pause / resume / abort, musisz zainstalować i skonfigurować "persistence service", coś, co jeszcze nie wiem, jak zacząć działać. Mogę skonfigurować bazę danych SQL dobrze, ale w czasie wykonywania dostaję kilka błędów, których nie rozumiem.
ponieważ jest z MS, nie wiesz, czy będzie wokół bardzo długo lub całkowicie upuszczone.
obsługa błędów jest trochę dziwna, ponieważ możesz użyć kodu za lub FaultHandler
przekazywanie danych z WF do głównej aplikacji jest skomplikowane i wymaga czegoś takiego jak WCF (inna technologia, której nie mam wystarczająco dużo czasu, aby się odpowiednio nauczyć), lub skorzystania z interfejsu ExternalDataExchange.