Czemu

Zanim opowiem jak, to chce się podzielić powodem dla którego to zrobiłem. Gdy pisałem kod, który cały mieścił się w jednym .csproj i mogłem go włączyć lokalnie i na spokojnie przedebugować (zaraz się zacznie) i upewnić że działa to było łatwiej. Kiedyś to było! Tutaj podszedłem do problemu inaczej; zrobię sobie funkcje które coś na szybko i na krótko zrobią, a potem cyk do kolejki, kolejne funkcja, cyk, kolejka, cyk cyk cyk i jest wynik. To jest ciekawa zabawa, ale cholernie trudna do utrzymania i do debugowania. Ja sobie nie ufam, dlatego też chce przetestować swój kod. Testowanie bez abstrakcji to zajęcie dla masochistów, lubię ostro, ale bez przesady.

Klasycznie gdy tworzy się nowy projekt mvc, webapi pojawia się tam plik startup.cs. Gdy tworzy się projekt z funkcjami takowego brak. To największa różnica, potem jest prościej.

Startup

Wszystko zaczyna się od dodania “startup.cs” – potem kod wygląda jakoś tak:

Ważne elementy to @2 referencja do nugeta Microsoft.Azure.Functions.Extensions. Następnie atrybut @6 dzięki któremu odpalimy się przy starcie funkcji i możemy działać.
@13 – @23 klasyczne rejestrowanie zależności, które jest znane z asp.net.

Gdzie

Jak z tego skorzystać? Ja nie zauważyłem dopisku i sądziłem, że przyjdzie to w wywołaniu metody, ale nie!. Funkcja (klasa i metoda) przestaje być statyczna i pojawia się konstruktor, tam przychodzi to co ma przyjść.

⭐I teraz tak: wiem że mam Function1 i Function1Worker – póki co tak ma być, kiedyś dorosną i dostaną swoje poprawne nazwy.

W konstruktorze @5 dostaje workera którego chciałem mieć, bo to on u mnie wykonuje całą robotę. Następnie w wywołaniu RunAsync strzelam do niego i żegnam się.

Inni beneficjenci

Sam worker też bardzo się uprościł, bo pamiętamy więcej-klas-mniej-kodu i wygląda tak:

Co w tym momencie pozwala mi wzrokiem stwierdzić, że raczej powinien działać (mam testy i tak!).

Uwaga

Największa różnica dla mnie w porównaniu z autofakiem z którego korzystam na co dzień jest taka, że tutaj jeśli coś się nie rozwiąże, to aplikacja przyśle wam nulla. Autofac będzie krzyczeć!
Także jeśli nie chcecie niespodzianek należy dołożyć NullGuard na parametry wejściowe, które będą wstrzykiwane.

Update:

Gdy nie zarejestrowałem zależności dla IFunction1Worker a próbowałem ją rozwiązać w Function1 wtedy leciał wyjątek o problemie zależności, funkcja nie była rejestrowana i przestawała być dostępna. Natomiast zależności dla “serwisów” nadal dostają cichego null’a – tutaj stabilnie.

Oficjalnie

Cała wiedze zaczerpnięta z tego msdn: https://docs.microsoft.com/en-us/azure/azure-functions/functions-dotnet-dependency-injection