Co można zrobić
Wysyłanie maili, aktualizowanie bazy danych, sprawdzaniem spójności danych, aktualizacje wpisów, boty, sztuczny ruch, te inne rzeczy można robić w tle naszej aplikacji, nie mówię że to najlepszy sposób – trzeba uważać na słówka.
Jak to robić dobrze? Na pewno nie odpalałbym osobnego wątku z aplikacji. Poszukałem i znalazłem u Hanselmana, mówiłem wam że mam z nim zdjęcie? Na blogu Scota jest taki wpis: http://www.hanselman.com/blog/HowToRunBackgroundTasksInASPNET.aspx
Ponieważ nie jestem uparty i nie lubię walczyć ze skomplikowanymi bibliotekami mój wybór padł na FluentScheduler. Sprawił mi najmniej problemów i najkrócej musiałem się zastanawiać, jak się z niego korzysta. Poza jednym szczegółem, ale o tym poniżej.
Klasycznie
Wszystko zaczyna się w jak zawsze w global.asax od takiej linijki:
IsThereAnyNewsScheduler.ScheduleRssUpdater();
W środku tworzymy nowy rejestr prac (polska język, trudna język):
Rejestr
Jak widać inicjalizacje tutaj także fabrykę, którą chciałbym spiąć z autofaciem, ale mi się nie udało, niżej krótkie wytłumaczenie. Rejestr może posiadać więcej niż jedną definicję prac.
Robota
W moim przypadku aktualnie jest to tylko jedna. Uruchomiona teraz, nie wchodząca sobie w paradę i uruchamiana co kolejne piętnaście minut.
Zdefiniowana w taki sposób:
Definicja roboty do zrobienia wygląda już bardzo prosto:
Konstruktor inicjalizacje wszystko co będzie potrzebne na później i sam 🙁 tworzy serwis z którym będzie później pracować. Następnie w Execute wywoływana jest metoda z najzwyklejszej klasy na świecie.
Smutek
Jak widzicie jestem smutny ponieważ, jestem wyznawcą wstrzykiwana zależności, niestety nie udało mi sie wygrać z tworzeniem zależności w autofacu bez HttpContextu – a z drugiej strony nie chciałem spędzić nad tym za dużo czasu. Także tutaj widać mały bałagan, który robi za nas IOC. Widać też jak dużo rzeczy wymaganych jest przez ten serwis, co każe myśleć nie czy, a raczej ile razy SRP został złamany. Łoszp – smagam się właśnie biczem po plecach – zły Jarek!
To właściwie tyle, odpalacie i zapominacie, a FluentScheduler robi robotę za was. Kod jak zawsze dostępny pod adresem: https://github.com/jstadnicki/isthereanynews
ps.
To już ostatni wymagany post w konkursie #dajsiepoznac.
Czy ten FluentScheduler odpala po prostu osobny wątek w ramach procesu IISa? Czy jest tam jakiś bardziej wyszukany mechanizm?
1. Abstrakcja mnie uwolni, nie przejmuje się tym
2. Za dokumentacją (…)To observe unhandled exceptions from your scheduled jobs, you will need to hook the JobException event on JobManager. That event will give you access to the underlying System.Threading.Tasks.Task and thrown exception details(…)
>>>System.Threading.Tasks.Task<<<