Omawiając warstwę biznesową wydaje mi się, że warto wspomnieć o technologii WWF. Kilka postów wcześniej pisałem o tzw. silniku reguł biznesowych. Chodziło o zdefiniowanie reguł oraz przepływu informacji w systemie. Jako przykład można podać wysyłanie zamówienia. Proces składa na pewno z kilku etapów takich jak aktualizacja bazy danych, wysłanie e-mail’a  z potwierdzeniem do klienta oraz np. wywołanie metody usługi sieciowej (może to być WCF magazynu). Po kilku miesiącach może okazać się, że scenariusz nie jest już wystarczający ponieważ doszły elektroniczne płatności i w obsłudze zamówienia trzeba uwzględnić czy klient wybrał opcję płatności przelewem(oczekiwanie na zatwierdzenie przelewu), kartą kredytową (walidacja) czy przy odbiorze (natychmiastowa wysyłka po weryfikacji). Oczywiście wszystko można zrealizować w czystym kodzie (tak większość osób dziś robi) i o ile nie popełni się jakiegoś błędu projektowego wszystko będzie sprawnie działać. Windows Workflow Foundation jednak znacznie to upraszcza i za pomocą rozbudowanego IDE często nie musimy pisać nawet czystego kodu.WWF pozwala nam definiować własne scenariusze biznesowe za pomocą różnych tzw. aktywności. Zamiast opisywać może lepiej od razu pokaże gotowy workflow (źródło MSDN):

Jak widać workflow składa się z pojedynczych aktywności. Większość rzeczy można zrealizować za pomocą IDE, przeciągając po prostu aktywności z toolbox’a. Ponadto jeśli okazałoby się, że w standardowym zestawie brakuje jakieś aktywności można bez problemu napisać własną (przypomina to trochę tworzenie własnego UserControl). Oprócz prostych if’ów oraz reguł, w standardowym zestawie występują również aktywności odpowiedzialne m.in za łączenie się z usługą sieciową, obsługę błędów (try, catch), transakcje, przetwarzanie współbieżne czy wykonanie po prostu fragmentu kodu c#.

Powyższy rysunek przedstawia Sequential Workflow. Rozwiązanie nadaje się dla pojedynczych scenariuszy takich jak złożenie zamówienia czy weryfikacja danych użytkownika. WWF pozwala jednak na zamodelowanie znacznie szerszego fragmentu logiki biznesowej poprzez wprowadzenie maszyny stanów. Projekt maszyny stanów oprócz oczywiście stanów zawiera przejścia (tranzycje) między nimi. Aktywowanie danego stanu może być wykonane np. za pomocą kodu, specjalnej aktywności czy odpalenia oczekiwanego zdarzenia. W systemie sprzedaży maszynę stanów można również wprowadzić do obsługi zamówień. Każde zamówienie ma pewien stan: oczekiwanie na zapłatę, weryfikacja, oczekiwanie na wysłanie, oczekiwanie na feedback. Podczas każdego stanu muszą być wykonywane pewne operacje takie jak  aktualizacja bazy danych czy wysłanie e-mail’a z informacją o zmianie stanu. Przykładowa maszyna stanów, którą miałem okazję ostatnio zaimplementować właśnie dla systemu sprzedaży:

Ponadto każdą aktywność można debuggować tak samo jak zwykły, czysty kod (za pomocą breakpoint, co widać na powyższym screenie).

Domyślnie, wszelkie informacje (zmienne, aktualny stan itp.) są przetrzymywane w pamięci ulotnej. W razie awarii i restartu komputera niemożliwe będzie odtworzenie poprzedniego stanu. Oczywiście w dużej części scenariuszy nie jest to problem ponieważ wykonanie poszczególnych sekwencji trwa bardzo krótko. Jeśli jednak zbudujemy maszynę stanów lub sequential workflow, których wykonanie trwa kilkanaście dni, WWF dostarcza również wsparcie w postaci usługi persystencji. Wszelkie informacje o stanie zamiast być zapisywane w pamięci ulotnej będą trafiały do bazy SQL Server. W takim przypadku maszyna stanów może być ciągle odpalona w tle i wykonywać pewne operacje. Częstym również scenariuszem użycia WWF jest wyeksponowanie go przez WCF.

W następnych postach będę kolejno pokazywał jak zrealizować przedstawione tutaj scenariusze. Cały czas równoległe będę również opisywał wzorce projektowe – przed nami jeszcze warstwa DAL, prezentacji oraz usług. Prawdopodobnie powstanie jeszcze kilka postów o design patterns w warstwie biznesowej. Zapraszam 🙂 !