W CQRS command bus ma za zadanie użyć odpowiedniego handlera do danej komendy. Wszystko ok tylko raz, że nie bardzo wiem jak to sensownie zaimplementować (jakaś mapa z kluczem w postaci command i wartością jako handler? Widziałem też implementacje oparte na refleksji.) a dwa, że nie bardzo widzę sens tej dodatkowej warstwy, bo przecież taki np rest controller może mieć wstrzykniętego po prostu odpowiedniego handlera i żaden command bus nie jest potrzebny albo ja czegoś nie widzę. (np. CreateUserController i wstrzyknięty do niego CreateUserHandler i tyle.)
No i jak kontroler ma obsłużyć np. 5 różnych poleceń, to będziesz mu wstrzykiwał 5 różnych handlerów, tak?
Właśnie po to używa się pośrednika, aby tego typu rzeczy unikać.
@somekind:
Nie, po prostu robiłbym controller per poleceń, co z resztą napisałem w pierwszym poście.
A po co tyle kontrolerów?
@somekind: No dobra, no to jak ten command bus zaimplementować z sensem?
np rest controller może mieć wstrzykniętego po prostu odpowiedniego handlera i żaden command bus nie jest potrzebny albo ja czegoś nie widzę
A co jeśli eventy mogą przychodzić różnymi drogami? RESTem, SOAPem, z jakiejś kolejki, periodycznie odczytywane z jakiejś bazy danych, może periodycznie pobierane z jakiegoś innego serwisu? Jeśli masz handler który jest częścią domeny
a nie jest bezpośrednio spięty z kontrolerem, to nie obchodzi cię nagle skąd przychodzi event. Ja bym zresztą od tego w ogóle zaczął -> od odcięcia domeny
aplikacji od technikaliów
jak jakieś kontrolery, bazy danych itd.
Sampeteq napisał(a):
@somekind: No dobra, no to jak ten command bus zaimplementować z sensem?
Jeśli musisz sam, to po prostu podejrzyj jak to robi konkurencja: https://github.com/jbogard/MediatR/blob/master/src/MediatR/Mediator.cs