Czy w aplikacji MVC zgodnej z CQRS viewmodele i komendy (zapytania) powinny być reprezentowane przez różne klasy? Czy jeśli mam np. CreateXCommand, to powinienem też mieć CreateXViewModel? Przy takim podejściu komenda jedynie opakowuje model widoku, czyli trzeba tworzyć wiele "nadmiarowych" klas, ale jaka jest alternatywa? Dziedziczenie viewmodeli po ICommand (IQuery) albo przekazywanie komend (zapytań) do widoku raczej nie pachnie dobrze.
0
2
Do api mogą przychodzić spokojnie command i query, a kontroler może je wysyłać na szynę. Jeśli jednak command lub query potrzebują dodatkowych informacji niż to co przyszło z zewnątrz to powinny to być oddzielne klasy. O dziedziczeniu viewmodeli z ICommand zapomnij.
0
Po dłuższym namyśle (wiem, dwa miesiące :p) stwierdzam, że MVC i CQRS (u mnie zaimplementowane przy użyciu MediatR) raczej do siebie nie pasują. Czy stosowanie MediatR jest warte duplikowania każdego viewmodelu? @Aventus Ty się znasz dobrze na MediatR. Co o tym sądzisz?
1
Jeśli nie robisz jakiegoś AOP w okół command/query, nie masz eventów, to nie potrzebujesz MediatR.
Do robienia CQRS, nie musisz mieć każdej komendy i query osobno, możesz jeśli to coś wniesie do systemu który tworzysz, a jak nic nie wnosi to tylko dodajesz nikomu niepotrzebnej złożoności przypadkowej.
2
nobody01 napisał(a):
Po dłuższym namyśle (wiem, dwa miesiące :p) stwierdzam, że MVC i CQRS (u mnie zaimplementowane przy użyciu MediatR) raczej do siebie nie pasują. Czy stosowanie MediatR jest warte duplikowania każdego viewmodelu? @Aventus Ty się znasz dobrze na MediatR. Co o tym sądzisz?
Ale co w tym złego, że masz klasy osobno do zapisu, osobno do edycji osobno do wyświetlania? Dla mnie dużą zaletą jest to, że każdą operację mogę mieć w osobnej klasie a wywołuje to z jednego miejsca. I jak sama nazwa wskazuje wydaję mi się, że głównym celem mediatR jest zaimplementowanie wzorca mediator.
2
.Czy stosowanie MediatR jest warte duplikowania każdego viewmodelu?
Troche blednie zadane pytanie. Podejrzewam ze w Twoim przypadku to nie wzorzec mediator wymusza "duplikowanie" view modelu, a fakt ze - calkiem slusznie- masz podzial na warstwy i warstwa domeny nie wie nic o widoku. Tak wiec naturalnie rezutatem zwracanym z handlera bedzie zwykle DTO bez danych metadancyh o widoku.Gdybys wszystko wrzucil do jednego worka to bys mogl zwracac sam model widoku, ale tego oczywiscie nie powinno sie raczej robic. Chyba ze piszesz naprawde prosty CRUD.
Druga sprawa to ze przy stosowaniu API i oddzielnego frontu zwracanym rezultatem bedzie wlasnie DTO, wiec zazwyczaj nawet nie trzeba nic duplikowac ani mapowac. W Twoim jednak przypadku pytasz o MVC- zastanowmy sie. Zwracasz jakies DTO jako wynik requestu/polecenia, oraz w warstwie UI mapujesz to na view model. Moim zdaniem nie ma w tym problemu, poniewaz Twoj view model moze miec dodatkowe informacje na temat chociazby formatowania wyswietlanych danych czy tez dodatkowe wlasciwosci zwracajace dane zbudowane z kilku innych juz gotowych wlasciwosci. Tak wiec czy jest sens posiadania dwoch klas tak zwiazanych (jedna tylko posrednio) z widokiem modelu? Tak, jesli chcesz zachowac odpowiedni podzial miedzy warstwami.
Jesli zas chodzi o komunikacje w druga strone, czyli wyslanie czegos z kontrolera do domeny to sprawa wyglada tak samo. Dodatkowo moim zdaniem komendy oraz zwracane obiekty powinny byc niemutowalne, a view model zazwyczaj posiada settery.
0
@Aventus: Wracam z innego tematu, bo za duży offtopic się zrobił ;) Chodziło mi o to, że zwracanie z handlera DTO, a następnie mapowanie go na ViewModel, który zawiera te same dane co DTO + metadane dla widoku, jak dla mnie jest oznaką przeinżynierowania w sytuacji, gdy mamy tylko MVC jako jedyną warstwę prezentacji. Chociaż korzyści wynikające z podziału na warstwy i projekty (czytelność kodu) są większe, to jednak są obecne klasy (DTO), które istnieją tylko po to, aby ten podział mógł mieć miejsce. Chociaż pewnie to jest zło konieczne. ;)
1
Tak, jest to zlo konieczne (w pewnym sensie). Do tego dochodza elementy ktore juz kiedys wymienialem:
- Niemutowalnosc DTO
- Dodatkowe, specyficzne dla widoku elementy w view modelu (np. atrybuty walidacji i formatowania)
Rowniez tak jak wspomnialem w innym watku, to co pisalem brzmialo jakbys mial zle wszystko porozdzielane. Ale moze to oddzielny temat. Reasumujac- tak, taki podzial moze nie miec sensu przy prostych aplikacjach, nigdzie tez do stosowania tego w takich przypadkach nie zachecalem. Natomiast kiedy tylko dochodzi bardziej rozbudowana logika biznesowa to szybko ujawniaja sie zalety takiej architektury.