W tym artykule pokażę jak utworzyłem prostą aplikację backendową, która wymaga autoryzacji z wykorzystaniem Auth0.

Aplikacja jest stworzona w technologii .Net core, zanim zacząłem nad nią pracę miałem już zainstalowany pakiet .Net Core SDK, aby je zainstalować należy wejść na stronę : https://dotnet.microsoft.com/download i wybrać swój system operacyjny i podążać za instrukcjami.

Praca nad aplikacją jest znacznie prostsza z użyciem Visual Studio, ewentualnie Visual Studio Code albo JetBrains Rider, ich instalacja nie jest jednak konieczna.

Tworzenie aplikacji rozpocząłem od wpisania w linię poleceń:

dotnet new web --name SzogunUI.RocketService

Polecenie to tworzy szkielet nowej aplikacji web o nazwie SzogunUI.RocketService

Następnie otworzyłem plik SzogunUI.RocketService\StartUp.cs i zmodyfikowałem metody Configure oraz ConfigureServices

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    app.UseMvc();
}

Linijki services.AddMvc() oraz app.UseMvc() sprawiają, że aplikacja wspiera wzorzec Mvc, czyli jest podzielona na 3 elementy: Model – zawierający struktury danych wykorzystywane do komunikacji między aplikacją a światem zewnętrznym, Widok (View) – w tej aplikacji nie wykorzystywany, oraz logikę aplikacji w kontrolerach (Controller).

Warunek sprawdzający env.IsDevelopment() sprawia, że w trakcie prac nad projektem aplikacja będzie zwracała dużą ilość szczegółów technicznych dotyczących przyczyny błędu.

Do katalogu SzogunUI.RocketService dodałem katalog Models, który zawiera Modele danych. Pierwszym z nich jest plik MissileType.cs zawierający następujący kod:

namespace SzogunUI.RocketService.Models
{
    public enum MissileType
    {
        Bb,
        Parabelum,
        Cruise,
        TsarBomba
    }
}

Jest to definicja typu wyliczeniowego (enum) zawierającego wszystkie typy pocisków jakie mogą być wysłane przez serwis.

Dodałem też klasę MissileSpec.cs zawierający klasę MissileSpec, opisującą ilość i typ pocisków wysyłanych przez użytkownika.

namespace SzogunUI.RocketService.Models
{
    public class MissileSpec
    {
        public MissileType Type { get; set; }
        public int Amount { get; set; }
    }
}

Następnie w katalogu SzogunUI.RocketLauncher utworzyłem katalog Controllers, a w tym katalogu umieściłem plik IndexController.cs zawierający następujący kod:

using Microsoft.AspNetCore.Mvc;
using SzogunUI.RocketService.Models;
namespace SzogunUI.RocketService.Controllers
{
    public class IndexController : Controller
    {
        [HttpGet]
        [Route("missile-types")]
        public IActionResult GetMissileTypes()
        {
            return Ok(new[]
            {
                MissileType.Bb,
                MissileType.Parabelum,
                MissileType.Cruise,
                MissileType.TsarBomba
            });
        }
        
        [HttpPut]
        [Route("locations/{latitude}/{longitude}")]
        public IActionResult PutMissilesToLocation(
            [FromRoute]double latitude, 
            [FromRoute]double longitude, 
            MissileSpec spec)
        {
            return Ok();
        }
    }
}

Zawiera on klasę IndexController będącą pierwszym kontrolerem w naszej aplikacji. Klasa dziedziczy po klasie Controller, nie jest to wymagane, ale ułatwia pracę. Zawiera ona dwie metody:

• GetMissileTypes – zwracającą tablicę dostępnych typów pocisków
• PutMissilesToLocation – pobierającą współrzędne geograficzne i specyfikację pocisków – odpowiedzialną za wysłanie pocisków w określoną lokalizację. Metodę pozostawiam pustą

Kod zawiera także inne elementy: Atrybuty Route definiują ścieżkę pod jaką dana metoda będzie dostępna np. Route(„missile-type”) mówi, że akcja będzie dostępna pod adresem [adres-serwera]/missile-types np. https://localhost:5001/missile-types. Atrybut HttpGet oznacza, że metoda służy do pobierania danych i że można ją wywołać po prostu wpisując w przeglądarkę odpowiedni adres, istnieją atrybuty HttpPut, HttpPost i HttpDelete, które oznaczają że metoda wymaga zapytania put, post albo delete, ręczne wywołanie metod oznaczonych tymi atrybutami wymaga narzędzi typu Postman, curl czy wtyczka do chrome Advanced REST Client. Serwis będzie wywoływany przez aplikacje klienckie, a nie bezpośrednio przez użytkowników, nie musisz się więc przejmować tym utrudnieniem.

Działanie atrybutu FromRoute na parametrze metody najłatwiej wyjaśnić na przypadku metody PutMissilesToLocation. Ścieżka (atrybut Route) zawiera fragmenty {latitude} i {longitude} odpowiednie parametry metody posiadają Atrybut FromRoute oznacza to , że Mvc spróbuje dopasować fragment ścieżki i przekazać go jako parametr metody np. użycie ścieżki /locations/52.20/21.00 spowoduje wysłanie pocisków w kierunku Mokotowa.

Ostatnim elementem użytym w tym fragmencie kodu jest metoda Ok, do której można przekazać parametr. Generuje ona odpowiedź mówiącą, że obsługa wywołania się udała, a jej opcjonalny parametr jest zamieniany w zwracany tekst. Istnieją inne metody takie jak BadRequest albo UnAuthorized, mówiące, że nie udało się przetworzyć wywołania i dające aplikacji klienckiej pewne wskazówki o przyczynie tego problemu.

Na tym etapie po uruchomieniu aplikacji da się z nią rozmawiać po http, np .wpisując w przeglądarkę https://localhost:5001/missile-types. Niestety zamiast nazw typów pocisków aplikacja zwraca: [0,1,2,3]. Aby to naprawić Należy do metody ConfiureServices w klasie Startup dodać wywołanie metody AddJsonOptions:

services
    .AddMvc()
    .AddJsonOptions(options => options.SerializerSettings.Converters.Add(new StringEnumConverter()));

Zaś w sekcji using dodać wpis

using Newtonsoft.Json.Converters;

Teraz metoda zwraca już poprawny wynik.

Obserwator i obserwowany

Wzorzec projektowy obserwatora i obserwowanego nie jest zbyt często wykorzystywany w aplikacjach .Net. Wiąże to się z faktem iż C# wspiera zdarzenia (events),  które w większości przypadków są rozwiązaniem wystarczająco dobrym. Microsoft zauważył jednak, że istnieją bardziej rozbudowane scenariusze, takie jak nasze, w których nie zdają one egzaminu, dlatego dodał interfejsy IObserver<T> i IObservable<T>. Różnią się one od klasycznej definicji książkowej tego wzorca kilkoma szczegółami:

• Są generyczne (parametryzowane typem) 
• IObservable zawiera tylko metodę Subscribe akceptującą jako parametr obserwatora i zwracającą obiekt implementujący IDisposable, zamiast wywołania metody Unsubscribe należy wywołać metodę Dispose z wyniku metody Register
• Obserwator posiada 3 metody OnNext, OnError i OnCompleted i jest bardziej skoncentrowany na obserwacji zmiany jednej wartości niż ogólnego stanu obserwowanego obiektu.

RX – Linq dla obserwatorów

LINQ jest bardzo potężnym fragmentem standardowej biblioteki .Net opartym o 2 proste interfejsy IEnumerable i IEnumerator. Sprawił że operacje na kolekcjach stały się tak proste, że większość programistów .Net prędzej zmieni pracę niż zrezygnuje z ich używania. LINQ jest zbiorem metod rozszerzających i wzorcu dekoratora: większość metod jako parametr przyjmuje instancję IEnumerable i ewentualnie inne parametry mające wpływ na zachowanie metody. Wewnątrz tej metody jest tworzona i zwracana instancja klasy implementującej IEnumerable, która akceptuje  parametry metody rozszerzającej jako parametry konstruktora. Metoda GetEnumerator tej klasy wywołuje metodę GetEnumerator oryginalnej kolekcji i przekazuje ją do konstruktora własnej klasy implementującej interfejs IEnumerator, wraz z parametrami swojego konstruktora. Dopiero ta klasa podczas wywoływania metody MoveNext analizuje parametry przekazane w konstruktorze i dokonuje decyzji czy wywoływać metodę MoveNext z oryginalnego Enumeratora, oraz jak przekształcić jej wynik, aby otrzymać docelową kolekcję.

Zarówno interfejs IEnumerable jak i IObservable opisują serię danych, pozwalają odczytywać kolejne elementy, oraz dostarczają informacji o tym czy seria zawiera więcej elementów. Podstawową różnicą jest fakt iż w przypadku IEnumerable to kod kliencki musi odczytywać kolejne elementy, a w przypadku IObservable to biblioteka wysyła kolejne elementy.

Na tym etapie utworzenie zestawu rozszerzeń do interfejsu IObservable wydaje się być dobrym pomysłem, tak właśnie powstała biblioteka Reactive Extensions. Pomysł okazał się tak dobry, że został zaadaptowany w większości języków programowania. Oprócz oryginalnej dokumentacji stworzonej przez Microsoft, powstała alternatywna wielo-platformowa dokumentacja pozwalająca lepiej zrozumieć koncepcje. Po zapoznaniu się z nią postanowiliśmy wykorzystać bibliotekę do implementacji jednej z funkcjonalności. Zaskoczył nas fakt iż pomimo, że integracja z RX nie była uwzględniona w oryginalnej wycenie zadania, udało się je dostarczyć na czas.

Dostarczanie wartości właściwości gdy zostaje podniesione zdarzenie

Jak wspominałem w pierwszej części artykułu API, z którego korzystamy składa się w większości z par właściwość – zdarzenie. Kluczowe więc dla nas było żeby istniał sposób na  dostarczenie wartości właściwości po podniesieniu zdarzenia. Na szczęście okazało się, że RX posiada odpowiednią metodę

var sizeObservable =
    Observable
        .FromEventPattern(
            handler => someObject.SizeChanged += handler,
            handler => someObject.SizeChanged -= handler)
        .Select(o => someObject.Size);

Ponieważ w większości przypadków nasz kod wymagał aby aktualna wartość właściwości natychmiastowo wyświetliła się na ekranie, stworzyliśmy własne rozszerzenie, które do powyższej metody dodawało dostarczenie tej wartości w momencie subskrypcji.

Komunikacja między wątkami

Ponieważ nasza aplikacja wykorzystuje wiele wątków, wsparcie przesyłania wiadomości pomiędzy wątkami była czymś czego oczekiwaliśmy. RX posiada metodę ObserveOn, która jako parametr przyjmuje obiekt typu Dispatcher. Niestety nie mogliśmy jej wykorzystać ponieważ inna biblioteka, którą wykorzystujemy, ukrywa ten obiekt pod własną abstrakcją. Na szczęście okazało się, że napisanie takiego rozszerzenia (Dispatch) własnoręcznie nie jest szczególnie trudne: 1 metoda rozszerzająca, 2 klasy mniej niż 100 linijek kodu.

Obserwowanie wielu źródeł na raz

Często to co użytkownik widzi na ekranie jest wyliczane na podstawie kilku wartości dostarczanych przez bibliotekę. Kolejną fukcjonalnością jakiej oczekiwaliśmy od RX była możliwość łączenia wartości z różnych źródeł. Rozwiązaniem jest metoda CombineLatest przyjmująca jako parametr kilka obiektów IObservable i funkcję która jako parametry akceptuje ostatnie znane wartości dostarczone przez obiekty Observable, a jako wynik zwraca wartość dostarczoną do obserwatora.

Observable
    .CombineLatest(
        firstObservable,
        secondObservable,
        thirdObservable,
        (firstValue, secondValue, thirdValue) => firstValue * secondValue * thirdValue);

Poprawa wydajności

Filtrowanie wartości

Podobnie jak LINQ, RX posiada metodę Where, pozwalającą usunąć z sekwencji wartości nie spełniających określonych warunków, odciążając w ten sposób obserwatora. Dodam że inne implementacje RX nazywają tą metodę Filter.

Usuwanie duplikatów

RX posiada metodę Distinct, która gwarantuje, że obserwator otrzyma każdą wartość tylko raz.W naszej aplikacji jednak okazało się, że znacznie bardziej użyteczna jest metoda DistinctUntilChanged, która usuwa duplikaty następujące po sobie. Ustawienie CombineLatest, DistinctUntilChanged i Dispatch w odpowiedniej kolejności pozwoliło wyeliminować większość nadmiarowej komunikacji między wątkami.

Debouncing

RX zwiera metodę Debounce. Która ogranicza częstotliwość dostarczania kolejnych wiadomości. Jest ona użyteczna jeżeli nowe wartości mogą przychodzą tak często, że użytkownik nie jest w stanie ich konsumować, a utrata części komunikatów nie jest problemem. Dobrym przykładem może tu być czujnik poziomu płynu chłodniczego, w trakcie jazdy po wyboistej drodze, gdy znajdujemy się w okolicach krytycznie niskiego poziomu. W takim przypadku czujnik co chwila wysyła informację, że wszystko jest OK albo że należy dolać płynu, to sprawia, że kontrolka na desce cały czas by mrugała denerwując użytkownika. Po zastosowaniu metody Debounce kontrolka zapalałaby się na kilka – kilkanaście sekund i gasła.

Testy jednostkowe

W naszym projekcie cały czas staramy się podnosić poziom pokrycia kodu testami. Jeżeli to ułatwia pracę stosujemy biblioteki Moq i NSubstitute. Niestety obie te biblioteki domyślnie zwracają null dla właściwości typu IObservable, co zmusza nas do rozszerzenia kodu inicjującego test. Nie jest to jednak tak uciążliwe na jakie wygląda.

Analiza problemów z produkcji

Podobnie jak LINQ i metody asynchroniczne, generuje bardzo długie i nieczytelne stosy wywołań. Czasami zdarza się, że w całym stosie nie ma żadnej linijki kodu należącej do naszej aplikacji.

Nie rezygnujemy z event-agregatora

Event agregator ma miejsce w naszym projekcie i nie planujemy go usuwać. Istnieją zdarzenia o których informujemy przy pomocy obydwóch mechanizmów.

Nasza podróż przez różne rozwiązania, nauczyła nas, że jeżeli istnieją różne rozwiązania jednego problemu, to każde z nich ma swoje wady i zalety, i nie należy się kurczowo trzymać jednego rozwiązania.

Wzorzec Event aggregator, zwany czasami mediatorem albo event busem, dostarcza kanału komunikacji pomiędzy modułami aplikacji, ograniczając powiązania między nimi: moduł wysyłający wiadomość nie ma pojęcia kto na niego zareaguje, nie wiem nawet czy ktokolwiek to zrobi. Moduł oczekujący na wiadomość zazwyczaj nie musi znać nadawcy, interesuje go tylko treść wysłanej wiadomości.

Modułem naszej aplikacji, w którym ten wzorzec jest szczególnie użyteczny, jest obszar powiadomień.

W aplikacji istnieje tylko jedna instancja klasy odpowiadającej za ten obszar, klasa ta nasłuchuje na zdarzenia wysyłane przez wiele różnych klas. Bez tego wzorca wyświetlenie powiadomienia o przyjściu nowej wiadomości wymagałoby śledzenia dostępności samego serwisu wiadomości, zmian na liście rozmów oraz zmian na liście wiadomości w każdej rozmowie. Co gorsza każdy moduł, który chciałby reagować na przyjście nowej wiadomości musiałby powtórzyć znaczną część tego kodu. Dzięki event-aggregatorowi ta część kodu jest napisana raz, w klasie która wysyła wiadomość, natomiast klasy zainteresowane przyjściem nowej wiadomości wywołują tylko jedną linijkę:

_messageAggregator.Register(MessageHandlingMethod);

Drugim problemem jakim rozwiązał ten wzorzec, jest komunikacja między wątkami. Napisaliśmy jedną metodę rozszerzającą do event-aggregatora, która przenosi obsługę powiadomienia na główny wątek aplikacji:

public static void RegisterOnDispatcher(
    this MessageAggregator self,
    DispatcherService dispatcherService,
    Action handler)
{
    self.Register(message => dispatcherService.Invoke(() =>f handler(message)));
}

Zrozumienie ciała metody wymaga chwili zastanowienia, jednak jej użycie jest proste:

_messageAggregator.RegisterOndispatcher(MessageHandlingMethod);

Problemy z event-aggregatorem

Wzorzec ten jest tak wygodny, że bardzo szybko zdominował znaczną część naszego kodu. W pewnym momencie zorientowaliśmy się jednak że powoduje on pewne problemy, a innych nie rozwiązuje.

Po pierwsze wiele klas wylicza swój stan początkowy na podstawie stanu serwisu, a na wiadomość zapisuje się żeby odświeżyć swój stan, co powoduje że każda z tych klas ma dwie zależności: serwis i event-aggregator.

Wysłanie wiadomości przez event-aggregatora wymaga napisania dodatkowej klasy, ponieważ programiści są z natury leniwi starają się pominąć ten krok gdy tylko jest to możliwe, nawet kosztem „wycieku abstrakcji”. Zdarzały się przypadki gdy mieliśmy serwis, który nasłuchiwał na zdarzenia z dwóch innych serwisów i wyliczał jakąś wartość, jednak nie wysyłał żadnego powiadomienia o zmianie tej wartości. Klasy które korzystały z tej klasy nasłuchiwały na zdarzenia z oryginalnych serwisów.

Nasza aplikacja pozwala na zmianę wielu ustawień „w locie”, czyli bez konieczności restartu aplikacji. W momencie zapisu ustawień „menadżer ustawień” wysyła wiadomość. Wiele klas jest na nią zarejestrowanych i wykonuje swoją logikę, nawet jeśli konkretne ustawienie nie uległo zmianie, aby ograniczyć ten efekt dodaliśmy do wiadomości dodatkową informację o tym, które wartości uległy zmianie, co jednak zmusza nas do dopisywania kilku dodatkowych linijek kodu za każdym razem gdy pojawia się nowe ustawienie.

W aplikacji pojawiły się problemy wydajnościowe związane z komunikacją między wątkami. Co prawda wywołanie metody Dispatcher.Invoke nie jest szczególnie ciężkie i nie należy się go bać, a już na pewno nie kosztem niepoprawnego działania programu, jednak wywoływanie jej kilkanaście tysięcy razy może przyprawić o zadyszkę nawet mocne komputery i spowodować „zawieszenie” się aplikacji. Wspomniana wcześniej metoda RegisterOnDispatcher powodowała, że „Handler” był uruchamiany na głównym wątku aplikacji, nawet w przypadkach gdy efektywnie nic nie robił np. pierwsza linijka obsługi zmiany ustawień zawierała sprawdzenie czy ustawienie, którego zmianą jest klasa jest zainteresowana, nie uległo zmianie. Trudniejszym do wyśledzenia przypadkiem był przypadek gdy ustawienie uległo zmianie, ale efektywna wartość wyliczona na jego podstawie pozostała bez zmian. W tej architekturze były to problemy bardzo trudne do naprawy.

W kolejnej części artykułu opiszę jak biblioteka Reactive Extensions rozwiązała nasze problemy.

Aby wygenerować aplikację użyjemy linii poleceń i komendy dotnet. 

dotnet new mvc --name Sample.Api.App

Jeżeli powyższa komenda nie działa prawdopodobnie powinieneś zainstalować .Net SDK

Aby upewnić się czy aplikacja działa wpiszmy  w linię komend

cd Sample.Api.App
dotnet restore
dotnet run

Poczekaj aż na ekranie pojawi się komunikat

Now listening on: https://localhost:5001
Now listening on: http://localhost:5000

I otwórz stronę https://localhost:5001/api/values strona powinna zawierać następujący tekst:

["value1","value2"]

Wróć do konsoli i wciśnij Ctrl+C

Udostępnijmy aplikację w chmurze

W poprzednim artykule proponowałem Ci zainstalowanie aplikacji cf-cli i założenie konta na stronie run.pivotal.io wszystkie dalsze fragmenty kodu będą zakładały, że tak właśnie zrobiłeś.

Aby udostępnić aplikację użyję narzędzia cf-cli. Narzędzie może współpracować z wieloma wdrożeniami CF dlatego należy wskazać środowisko na którym aplikacja ma zostać wdrożona:

cf api api.run.pivotal.io

Aplikacja musi też znać login i hasło, aby je podać należy użyć polecenia:

cf login

po podać login i hasło użyte podczas rejestracji. Ostatnim krokiem jest „wypchnięcie” aplikacji do chmury, aby to zrobić wpisz w linię poleceń:

cf push sample-api --random-route

Parametr sample-api to nazwa aplikacji, która jest obowiązkowa. Parametr –random-route jest opcjonalny i oznacza, że chmura wylosuje dla nas ścieżkę, pod którą aplikacja będzie dostępna. Pominięcie tego parametru sprawi, że narzędzie spróbuje opublikować aplikację pod adresem: sample-api.cfapps.io, który prawdopodobnie będzie zajęty ze względu na fakt, iż jest to środowisko współdzielone przez wielu użytkowników. Ścieżkę można też ustawić ręcznie podając parametr –route

cf push sample-api --route moja-unikalna-personalna-sciezka

Co spowoduje próbę publikacji pod adresem moja-unikalna-personalna-sciezka.cfapps.io

Narzędzie powinno wyświetlić masę tekstu kończącego się czymś podobnym do:

Waiting for app to start...

name:              sample-api
requested state:   started
routes:            sample-api-optimistic-porcupine.cfapps.io
last uploaded:     Thu 06 Sep 20:47:01 CEST 2018
stack:             cflinuxfs2
buildpacks:        dotnet-core

type:            web
instances:       1/1
memory usage:    1024M
start command:   cd ${DEPS_DIR}/0/dotnet_publish && ./Sample.Api.App
                 --server.urls http://0.0.0.0:${PORT}
     state     since                  cpu    memory    disk
#0   running   2018-09-06T18:47:17Z   0.0%   0 of 1G   0 of 1G

Linijka zaczynająca się od „routes:” wskazuje adres aplikacji. W moim przypadku jest to: „sample-api-optimistic-porcupine.cfapps.io”, jeżeli wszystko poszło dobrze po otworzeniu w przeglądarce adresu https://[ścieżka aplikacji]/api/values (w moim przypadku https://sample-api-optimistic-porcupine.cfapps.io/api/values) powinniśmy ponownie zobaczyć stronę zawierającą:

["value1","value2"]

W kolejnym artykule opowiem co w tym procesie można zrobić lepiej.

Jeden z produktów jakie ostatnio rozwijaliśmy w naszym zespole, jest aplikacją desktopową opartą o rozbudowaną bibliotekę, która dostarczała spójne API do komunikacji, opartej o różne protokoły związane z telekomunikacją, co sprawiało że generowała naprawdę dużo sygnałów.

Architektura biblioteki

Większość klas w tej bibliotece pasowała do takiego wzorca:

public class Class1
{
    public void SetDescription(string description, CompletionHandler handler)
    {
         /* Some logic here */
    }

    public void SetSize(int size, CompletionHandler handler)
    {
        /* Some logic here */
    }

    public string Description { get; private set; }

    public int Size { get; private set; }

    public event EventHandler DescriptionChanged;

    public event EventHandler SizeChanged;
}

• Metody SetDescription i SetSize wysyłają wartość przekazaną jako pierwszy parametr i wywołują metodę przekazaną jako Handler gdy serwer potwierdzi albo odrzuci żądanie
• Właściwości Description i Size zwracają ostatnią znaną wartość
• Zdarzenia DescriptionChanged i SizeChanged są uruchamiane gdy serwer powiadomi aplikację o zmianie wartości – niezależnie czy zmiana była spowodowana przez wywołanie metody Set* czy przez inne interakcje z serwerem np. działanie drugiej aplikacji

Biblioteka przetwarza wszystkie żądania na swojej własnej wewnętrznej puli wątków co ma swoje zalety i wady. Podstawową zaletą był fakt iż biblioteka, sama z siebie, nie wpływała na działanie wątku głównego aplikacji. Wadą był fakt iż wszystkie callbacki i zdarzenia podnoszone przez bibliotekę były uruchamiane na innym wątku, co wymuszało opracowanie jakiegoś mechanizmu do komunikacji między wątkami.

Ręczne zarządzanie wątkami – Nie chcesz tego robić

Już od początku rozwoju aplikacji zorientowaliśmy się, że ręczna komunikacja między wątkami kończy się powstaniem dużej ilości długiego i powtarzalnego kodu, który wygląda mniej więcej tak:

public class SomeOtherClass : IDisposable
{
    private readonly SomeClass _someObject;
    private readonly DispatcherService _dispatcherService;

    public SomeOtherClass(
        SomeClass someObject,
        DispatcherService dispatcherService)
    {
        _someObject = someObject;
        _dispatcherService = dispatcherService;

        _someObject.DescriptionChanged += SomeObjectOnDescriptionChanged;
        _someObject.SizeChanged += SomeObjectOnSizeChanged;
    }
    
    private void SomeObjectOnDescriptionChanged(object sender, EventArgs e)
    {
        _dispatcherService.Invoke(LoadState);
    }

    private void SomeObjectOnSizeChanged(object sender, EventArgs e)
    {
        _dispatcherService.Invoke(LoadState);
    }

    private void LoadState()
    {
        PropertyVisibleOnUI = $"Description: {_someObject.Description} Size: {_someObject.Size}";
    }
    
    public string PropertyVisibleOnUI { get; set; }

    public void Dispose()
    {
        _someObject.DescriptionChanged -= SomeObjectOnDescriptionChanged;
        _someObject.SizeChanged -= SomeObjectOnSizeChanged;
    }
}

Kod staje się jeszcze bardziej złożony jeżeli założymy, że niektóre właściwości klasy są złożonymi obiektami, które mają właściwości, zdarzenia, metody asynchroniczne. A takich warstw może być znacznie więcej.

API do obsługi wiadomości tekstowych napisane w tej konwencji mogło wyglądać tak:

public interface IConversationService
{
    event EventHandler ConverstionStarted;
    event EventHandler ConversationEnded; 
    IEnumerable Conversations { get; }
}

public interface IConversation
{
    event EventHandler MessageAdded;
    void SendMessage(string body, CompletionHandler handler); 
    IEnumerable Messages { get; }
}

public interface IMessage
{
    event EventHandler IsReadChanged;
    bool IsMine { get; }
    string Body { get; }
    bool IsRead { get; }
}

Koniecznie potrzebowaliśmy lepszego rozwiązania. W drugiej części artykułu opiszę jak wzorzec event-aggregator pomógł nam pokonać te problemy.

Zacznę od takiego niewinnego kawałku kodu:

class Adapter
{
    public Task<int> GetNextInt()
    {
        var api = new CallbacksApi();
        var taskCompletionSource = new TaskCompletionSource<int>();
    
        api.GetNextInt((result, exception) =>
        {
            if (exception != null)
            {
                taskCompletionSource.SetException(exception);
            }
            else
            {
                taskCompletionSource.SetResult(result);
            }
        });
        
        return taskCompletionSource.Task;
    }
}

Kod wydaje się poprawny. Co lepsze będzie działać w czasie testów dymnych, prawdopodobnie przejdzie testy funkcjonalne. Kod ten może jednak powodować pojawianie się błędów typu: „Ta operacja czasami nie kończy się przez pół godziny”, „aplikacja chodzi wolno” albo „program się zawiesza”. Co gorsza nikt nie będzie w stanie dostarczyć powtarzalnego scenariusza.

Winnym okazuje się być Garbage Collector, który może w tym przypadku błędnie stwierdzić, że nikt nie potrzebuje obiektu CallbacksApi, bo nikt nie posiada do niego referencji.

Pierwszym sposobem „obejścia” tego problemu może być „przytrzymanie” referencji do API w jakimś obiekcie, który żyje dłużej. W kodzie powyżej może być to klasa obiekt typu Adapter.

class Adapter
{
    private CallbacksApi _api = new CallbacksApi();
    public Task<int> GetNextInt()
    {
        var taskCompletionSource = new TaskCompletionSource<int>();
    
        _api.GetNextInt((result, exception) =>
        {
            if (exception != null)
            {
                taskCompletionSource.SetException(exception);
            }
            else
            {
                taskCompletionSource.SetResult(result);
            }
        });
        
        return taskCompletionSource.Task;
    }
}

Sprawa się komplikuje gdy nowe CallbacksApi musi być tworzone z każdym wywołaniem GetNextInt. Brzydkim ale szybkim obejściem tego problemu jest użycie kolekcji:

class Adapter
{
    private List<CallbacksApi> _apiReferences = new List<CallbacksApi>();
    private object _apiReferencesLockRoot = new object();
    public Task<int> GetNextInt()
    {
        var api = new CallbacksApi();
        var taskCompletionSource = new TaskCompletionSource<int>();
        lock(_apiReferencesLockRooti)
        {
            _apiReferences.Add(api);
        }
    
        api.GetNextInt((result, exception) =>
        {
            lock(_apiReferencesLockRooti)
            {
                _apiReferences.Add(api);
            }
            if (exception != null)
            {
                taskCompletionSource.SetException(exception);
            }
            else
            {
                taskCompletionSource.SetResult(result);
            }
        });
        
        return taskCompletionSource.Task;
    }
}

Ten kod działa ale wszyscy się chyba zgodzą że najładniejszy to on nie jest. W dodatku jeżeli referencja do obiektu typu Adapter nie jest nigdzie przetrzymywana przez dłuższy czas to powyższe rozwiązania i tak nie zadziałają. Na szczęście Microsoft pomyślał o tym problemie i TaskCompletionSource posiada dodatkowy parametr konstruktora „state”, którego można przekazać cokolwiek. Obiekt ten jest przypisany do właściwości AsyncState wynikowego Taska, przez co GC zostawi go w spokoju.

class Adapter
{
    public Task<int> GetNextInt()
    {
        var api = new CallbacksApi();
        var taskCompletionSource = new TaskCompletionSource<int>(api);
    
        api.GetNextInt((result, exception) =>
        {
            if (exception != null)
            {
                taskCompletionSource.SetException(exception);
            }
            else
            {
                taskCompletionSource.SetResult(result);
            }
        });
        
        return taskCompletionSource.Task;
    }
}

Kod klas, które stworzyłem na potrzeby tego wpisu znajduje się w tym punkie Githuba, natomiast testy do nich tutaj. Testy zwracają oczekiwany wynik tylko po zbudowaniu projektu w trybie Release, a właściwie to nie do końca zwracają. Test dla klasy FixedAdapter przechodzi i tak ma być. Test dla klasy BrokenAdapter nie przechodzi i to także jest zgodne z moimi oczekiwaniami.

Mam natomiast problem z testem dla klasy WorkedAroundAdapter, teoretycznie linijka Assert.NotNull(adapter) powinna sprawić że test przejdzie, ten jednak przejść nie chce i nie mam pojęcia dlaczego. Postanowiłem więc postawić znaczną ilość piwa, zgrzewkę 24 Tyskiego albo jego równowartość w innym gatunku, pierwszej osobie która mi to wytłumaczy.

public class Proxy
{
    void Method1(int argument);
    event EventHandler<EventArgs<Result1>> Method1Completed;
    event EventHandler<FailureEventArgs> Method1Failed;

    void Method2();
    event EventHandler<EventArgs<Result2>> Method1Completed;
    event EventHandler<FailureEventArgs> Method1Failed;
}

Ale poczułem się staro. Podobny wzorzec był stosowany też w innych technologiach. Ma on wiele wad w porównaniu do kolbaków. Na początek nie istnieje żadna gwarancja że jeżeli wywołam Method1 z argumentem 1 po czym wywołam Method1 z argumentem 2 to event Method1Completed dla 1 przyjdzie przed tym samym eventem dla 2. Na potrzeby dalszych rozważań uznam, że opakowanie w Task i użycie słów async i await sprawi że wywołanie z 2 nie nastąpi przez eventem dla 1, co nie musi być prawdą ale zazwyczaj jest.

Podejście to sprawdza się nie źle w jednym przypadku: akcja się wywołuje jak się uda podejmowane jest jedno zawsze to samo działanie, jak nie to drugie.

// Constructor
public ClientClass()
{
    _eventApi = new EventApi();
    _eventApi.GetNextIntCompleted += EventApiOnGetNextIntCompleted;
    _eventApi.GetNextIntFailed += EventApiOnGetNextIntFailed;
}

private void EventApiOnGetNextIntCompleted(object sender, ResultEventArgs resultEventArgs)
{
    MessageBox.Show(resultEventArgs.Result);
}

private void EventApiOnGetNextIntFailed(object sender, FailureEventArgs failureEventArgs)
{
    MessageBox.Show("Something gone wrong");
}

Sytuacja jednak komplikuje się znacząco gdy w momencie zakończenia zadania potrzebna jest informacja znana przy jego rozpoczęciu:

public void GetNextIntForClient(Client client)
{
    EventHandler<ResultEventArgs> successHandler = null;
    EventHandler<FailureEventArgs> failureHandler = null;
    
    successHandler = (sender, args) =>
    {
        _eventApi.GetNextIntCompleted -= successHandler;
        _eventApi.GetNextIntFailed -= failureHandler;
        MessageBox.Show(string.Format("{1} was chosen for client {0}", client.Name, args.Result));
    };

    failureHandler = (sender, args) =>
    {
        _eventApi.GetNextIntCompleted -= successHandler;
        _eventApi.GetNextIntFailed -= failureHandler;
        MessageBox.Show(string.Format("Unable to choose value for client {0}", client.Name));
    };
    
    _eventApi.GetNextIntCompleted += successHandler;
    _eventApi.GetNextIntFailed += failureHandler;

    _eventApi.GetNextInt();
}

Dla porównania kod oparty o async/await

public async void GetNextIntForClient(Client client)
{
    try
    {
        await _taskApi.GetNextInt();
        MessageBox.Show(string.Format("{1} was chosen for client {0}", client.Name, args.Result));
    }
    catch (Exception exception)
    {
        MessageBox.Show(string.Format("Unable to choose value for client {0}", client.Name));
    }
}

Opakowanie zdarzeń w zadania nie jest proste i opiera się na kodzie podobnym do tego w metodzie GetNextIntForClient:

public Task<int> GetNextInt()
{
    var completionSource = new TaskCompletionSource<int>();

    EventHandler<ResultEventArgs> successHandler = null;
    EventHandler<FailureEventArgs> failureHandler = null;

    successHandler = (sender, args) =>
    {
        _eventApi.GetNextIntCompleted -= successHandler;
        _eventApi.GetNextIntFailed -= failureHandler;
        completionSource.TrySetResult(args.Result);
    };

    failureHandler = (sender, args) =>
    {
        _eventApi.GetNextIntCompleted -= successHandler;
        _eventApi.GetNextIntFailed -= failureHandler;
        completionSource.TrySetException(args.Error);
    };

    _eventApi.GetNextIntCompleted += successHandler;
    _eventApi.GetNextIntFailed += failureHandler;

    _eventApi.GetNextInt();

    return completionSource.Task;
}

Sporo kodu… wypadałoby go skrócić. Napisanie uniwersalnego helpera jest jednak trudniejsze niż się wydaje. Jednym z problemów jest, wspomiany w poprzednim artykule, brak mapowania delegat „w locie”. Z moich doświadczeń wynika jednak, że twórcy API zazwyczaj korzystają z typów: EventHandler oraz EventHandler<T>, a nawet jeżeli używają innych typów to są spójni w zakresie swojego API. Więc całkiem rozsądne okazuje się napisanie klasy będzie zawierać powtarzający się kod

sprawi że opakowanie API opartego o eventy w zadania skróci się do:

public async Task<int> GetNextIntWithArg(string arg)
{
    var eventToTask = new EventToTask<ResultEventArgs>(
        handler => _eventApi.GetNextIntCompleted += handler,
        handler => _eventApi.GetNextIntCompleted -= handler,
        handler => _eventApi.GetNextIntFailed += handler,
        handler => _eventApi.GetNextIntFailed -= handler,
        () => _eventApi.GetNextInt());
    var eventArgs = await eventToTask.Invoke();
    return eventArgs.Result;
}

Znacznie lepiej ale dalej fatalnie. Problemem, który widać na pierwszy rzut oka, jest konieczność pisania powtarzalnego kodu w którym łatwo się pomylić. W dodatku w przypadku pomyłki programista nie zostanie ostrzeżony podczas kompilacji, ten błąd może zostać także niezauważony przez długi czas przez wszystkie formy testu i objawić się wyciekiem pamięci albo trudnym do odtworzenia crashem. Drugim problemem, którego nie widać, jest fakt iż kompilator wygeneruje na potrzeby tego kodu 6 klas których obiekty będzie tworzył przy wywołaniu tej metody. Zazwyczaj nie jest to duży problem ale można go łatwo ograniczyć zmieniając implementację EventToTask.

Użycie wygląda podobnie:

var eventToTask = new EventToTask<EventApi, ResultEventArgs>(
    _eventApi,
    (context, handler) => context.GetNextIntCompleted += handler,
    (context, handler) => context.GetNextIntCompleted -= handler,
    (context, handler) => context.GetNextIntFailed += handler,
    (context, handler) => context.GetNextIntFailed -= handler,
    context => context.GetNextInt());
    
var eventArgs = await eventToTask.Invoke();
return eventArgs.Result;

Sposobem na zwiększenie wykrywalności i zmniejszenie występowania problemów związanych z pomyłkami programisty w tym kodzie wydaje się być użycie klasy Expression. Przykładowy kod jest trochę przy długi zapraszam do zapoznania się znim na Githubie

Użycie tej klasy jest dość proste:

var eventToTask = EventToTask
    .Create(_eventApi)
    .WithTrigger(context => context.GetNextInt())
    .WithResultEvent<ResultEventArgs>((context, handler) => context.GetNextIntCompleted += handler)
    .WithFailureEvent((context, handler) => context.GetNextIntFailed += handler)
    .Build();
var eventArgs = await eventToTask.Invoke();
return eventArgs.Result;

jest tylko jeden taki _{malutki problemik}: ten kod się nie kompiluje. Niestety parametr typu Expression<T> nie może przyjąć lambdy zawierającej operator +=. Z drugiej strony po za klasą w której zdarzenie jest deklarowane jedynymi dozwolonymi operatorami które mogą go modyfikować są += i -=.

Podsumowując opieranie asynchroniczności o zdarzenia jest zazwyczaj pomyłką architektoniczną i rodzi problemy. Daje się jednak z nią żyć.

Kody źródłowe

Kod źródłowy projektu stworzonego na potrzeby tej serii udostępniam na Githubie

Wielu z nas, programistów, jest jednak do dzisiaj zmuszonych pisać asynchronicznie tak jak (nie)potrafi i tak środowisko im na to (nie)pozwala. Nawet w C# sytuacja nie wygląda kolorowo, klasa Task umożliwia użycie jej w tandemie z async i await zaledwie od 4 lat. Żaden kod napisany przez pierwsze 11 lat istnienia .Net nie miał szans ich użycia. Kod napisany później także niekoniecznie z niego korzysta.

Myślę, że w takiej sytuacji adaptacja starego API na własną rękę może być opłacalna, dlatego postanowiłem popełnić serię artykułów pokazujących jak można się za to zabrać.
Na szczęście Microsoft szybko zauważył problem adaptacji starego kodu do nowego wzorca, czego efektem jest TaskCompletionSource, który umożliwia przetworzenie czegokolwiek na Task’a.

W pierwszej części chciałbym pokazać adaptację API opartego na kolbakach (ang.callbacks) i obiecankach (ang. Promises).

Wiele angielskich słów nie ma idealnego tłumaczenia, „callback” nie jest tu wyjątkiem. Programiści rozumieją je jako „wywołanie zwrotne”, jednak nikt tak nie mówi, na co dzień używam pięknego słowa „kolbak” i tak będę robił dalej. Dla niewtajemniczonych kolbak opisuje rozwiązanie, w którym metoda jako jeden z argumentów przyjmuje inną metodę, która jest wywoływana po zakończeniu operacji.

public void GetNextInt(Action<int> callback)
{
    /* Magic in here */
    callback(123);
}

„We will call back to you” w dosłownym tłumaczeniu oznacza „Oddzwonimy do ciebie”. Często to słyszymy, a jak często otrzymujemy telefon gdy coś pójdzie nie tak? I jak się czujemy gdy ktoś długo nie oddzwania? Podobnie czuje się kod i programista, który go napisał, gdy wywołuje metodę z kolbakiem, a ten nigdy nie następuje. Dlatego dobrą praktyką jest przekazanie kodu błędu albo wyjątku jako dodatkowego parametru kolbaka.

public void GetNextInt(Action<int, Exception> callback)
{
    try
    {
        /*Magic in here*/
        callback(123, null);
    }
    catch(Exception ex)
    {
        callback(default(int), ex);
    }
}

Kolbaki nie są niczym nowym, bo praktycznie każda technologia je wspiera: C++, Javascript, Python, PHP, Java (….aaa nie, przepraszam! Java jednak nie :D), dlatego adaptacja takiej metody do czegoś, co zwróci Taska z wykorzystaniem TaskCompletionSource to nic trudnego.

public Task GetNextInt()
{
    var completionSource = new TaskCompletionSource();

    GetNextInt((result, exception) =>
    {
        if (exception != null)
        {
            completionSource.SetException(exception);
        }
        else
        {
            completionSource.SetResult(result);
        }
    });

    return completionSource.Task;
}

Taki kod może spowodować przewrócenie się aplikacji. Może się zdarzyć się że callback zostanie wywoływany kilka razy (kompilacja tego nie pilnuje). TaskCompletionSource nie lubi wielokrotnego wywoływania SetException albo SetResult i zgłasza wyjątek. W takim wypadku należy upomnieć twórcę kodu że robi źle, jeżeli to nie pomaga należy użyć środków przymusu bezpośredniego, jak to nie skutkuje należy upewnić się że napisał taki kod ostatni raz. Jeżeli jednak i to jest niemożliwe, ponieważ ktoś już go zdążył zastrzelić należy spróbować zorientować który kolbak jest tym właściwym, jeżeli pierwszy jest dobry wystarczająco to klasa TaskCompletionSource posiada metody TrySetResult i TrySetException, które nie powodują wyjątku przy wielokrotnym wywoływaniu.

Powyższy kod może nie jest może skomplikowany, ale przy pisaniu go 20 raz można się pomylić, dlatego dobrym pomysłem może być napisanie takiego helpera:

public Task Invoke<T>(Action<T> methodToInvoke)
{
    var completionSource = new TaskCompletionSource<T>();
    methodToInvoke((result, exception) =>
    {
        if (exception != null)
        {
            completionSource.SetException(exception);
        }
        else
        {
            completionSource.SetResult(result);
        }
    });
}

Po jego użyciu kod skraca się do:

public Task GetNextInt()
{
    return Invoke(GetNextInt);
}

Kiedy natomiast metoda przyjmuje argumenty:

public Task GetNextInt(string argument)
{
    return Invoke((handler) => GetNextInt(argument, handler));
}

Użycie takiego helpera ma sens w sytuacji, kiedy API używa typu Action jako callbacka, ale również w memencie kiedy API używa innego typu (wtedy najlepiej jest użyć go do zmiany typu przyjmowanego jako argument helpera).

Problem zaczyna się gdy API używa callbacków różnego typu, ale jak już wspomniełem nasz staruszek C# ma wiele ograniczeń i nie potrafi „w locie” przetłumaczyć typów oznaczanych słowem delegate, nawet jeżeli mają takie same wejścia i wyjścia. Przykładem może być Action<object, eventarg=””> – nie da się przekazać tej akcji jako EventHandler. W takiej sytuacji można pisać wszystko z palca, napisać generator kodu lub odpuścić i wyciągnąć jakieś wnioski na przyszłość.</object,>

Promise (obiecanki-cacanki)

Obiecanki to bardzo popularny mechanizm używany w wielu technologiac, w .Net raczej nie występuje, gdyż pojawiło się async/await, jednak można spotkać pewne chałupnicze implementacje. Po co jednak słowa – lepiej będzie, gdy spojrzycie na kod, gdyż wyraża on więcej niż tysiąc słów. Jeżeli w aplikacji występuje taki kod:

GetNextInt()
    .OnDone(result => {
        /* Wyświetl wynik */
        MessageBox.Show("Wynik to " + result);
    }).OnError(error => {
        MessageBox.ShowError("Coś poszło nie tak.")
    }).Always(() => {
        /* Schowaj kręcioła */
        HideSpinner();
    });

to na 99% GetNextInt zwraca Promise ewentualnie Future. Adaptacja Promise do klasy Task jest nawet łatwiejsza niż kolbaka, sami zobaczcie:

public Taks<T> Wrap(this IPromise<T> promise)
{
    var taskCompletionSource = new TaskCompletionSource<T>();
    promise
        .OnDone(result => {
            taskCompletionSource.SetResult(result)
        }).OnError(error => {
            taskCompletionSource.SetException(error);
        });
    return taskCompletionSource.Task;
}

ale może być jeszcze łatwiejsza:

public Taks<T> Wrap<T>(this IPromise<T> promise)
{
    var taskCompletionSource = new TaskCompletionSource<T>();
    promise
        .OnDone(taskCompletionSource.SetResult)
        .OnError(taskCompletionSource.SetException);
    return taskCompletionSource.Task;
}

Na dziś – tyle. Jednak to jeszce nie koniec … cdn.

Kod źródłowy projektu stworzonego na potrzeby tego postu udostępniam na Githubie

Metoda miała i tak być odpalona w trybie „Fire and forget” więc uznałem wpisywanie tych kilkunastu znaków za stratę czasu i puściłem moduł na testy, które to testy moduł przeszedł. Jednak w przeciągu tygodnia użytkownicy zaczęli się skarżyć że aplikacja się przewraca w losowych momentach. Logi wskazywały, że mechanizm globalnej obsługi wyjątków loguje błąd o szczegółach podobnych do następujących:

Niewiele da się z tego odczytać. Uratował mnie jednak fakt iż typ wyjątku był mi bardzo dobrze znany (i nie był to System.Exception).
Dodanie awaita sprawiło, że stos zaczął wyglądać po ludzku:

Przygotowałem też programik obrazujący problem: https://github.com/szogun1987/TaskExceptions
Błąd wykazuje największą powtarzalność po zbudowaniu w wersji Release. Gdyby błąd nie chciał wystąpić należy wcisnąć przycisk GC.Collect.

Problem, który odkryłem, dotyczy drugiego parametru konstruktora. I aby go lepiej naświetlić przedstawię przypadek użycia, w którym on wystąpił.
Aplikacja posiada ustawienia zapisywane na dysku, które mogą być zmieniane w dedykowanym module. Moduł posiada przyciski „Zapisz” i „Anuluj” – pozwalające opuścić moduł. Operacja zapisz zamyka moduł tylko gdy ustawienia przechodzą walidację. Aplikacja na starcie wykrywa czy zapisane ustawienia spełniają te reguły (nie spełniają przy świeżej instalacji oraz jak ktoś usunie plik z dysku), jeżeli nie otwiera moduł ustawień, w tym konkretnym przypadku przycisk anuluj ma być trwale wyłączony. I ten przypadek działał bez zarzutów. Czasami (powtarzalność około 30%) przycisk „Anuluj” był wyłączony przy „ręcznym” odpaleniu modułu. Błąd dał się odtworzyć na mojej maszynie. Jednak gdy przyjrzałem mu się w trybie Debug zobaczyłem że komenda po wywołaniu CanExecute zawsze zwraca true.

Jednak przycisk mimo to bywał wyłączony. Błąd wynikał z połączenia kilku czynników. Po pierwsze flagę określającą czy przycisk ma być włączony wyliczałem w konstruktorze i wrzucałem do lambdy w komendzie, nigdzie jej nie przechowując bo nie była mi nigdzie indziej potrzebna. Po drugie referencja do metody przekazanej jako parametr CanExecute w RelayCommand jest przetrzymywana z wykorzystaniem WeakReference i jeżeli znikną wszystkie inne referencje do niej zostanie sprzątnięta przez Garbage Collector. W tym przypadku po wywołaniu metody CanExecute na obiekcie RelayCommand zostanie zwrócona wartość false (asekuracyjnie). Błąd występował jeżeli GC zdążył sprzątnąć moją lambdę zanim została użyta. Jeżeli nie zdążył to moduł działał poprawnie.
Jak rozwiązać ten problem? Po pierwsze można stworzyć własną implementację ICommand nie korzystającą z WeakReference. To rozwiązanie będzie niewątpliwie będzie działać. Problem w tym, że może powodować inne bugi, głównie wycieki pamięci w pewnych skrajnych przypadkach (np. gdy jako parametr przekażemy wyrażenie Lambda wykorzystujące pole statyczne). Po za tym nie po to dodaliśmy MVVM Light żeby rezygnować z jednej z najfajniejszych zabawek. Drugim rozwiązaniem jest powiązanie parametru canExecute z ViewModelem, co sprawi że GC nie posprząta jej tak długo jak ViewModel będzie żył. Można to zrobić przynajmniej na 2 sposoby: w wyrażeniu lambda przekazywanym do RelayCommand użyć przynajmniej 1 pola z klasy (może być to pole ReadOnly) albo jako parametr przekazać niestatyczną metodę z klasy.
Na koniec podaję linka do aplikacji obrazującej błąd: https://github.com/szogun1987/MvvmLightBugExample

Edit 27.01.2017:

Do MVVM Light zostało dodane obejście pozwalające naprawić ten błąd. Do konstruktora RelayCommand został dodany parametr „keepTargetAlive”. Jeżeli zostanie tam przekazane true błąd przestanie występować.