CQRS patternben ez melyik típushoz tartozik?
2020-12-31T15:53:13+01:00
2021-01-06T22:20:30+01:00
2022-08-12T00:12:25+02:00
*deleted_39885489
Van egy web api végpont, amivel a client kérhet authentikációs tokeneket.  (jwt, refresh)
api/token/create

Itt elvileg egy query lenne, ami vissza adja a két tokent, viszont a refresh tokent meg az adatbázisba kell írjam, ami meg a command felelősége lenne, mert ugye csak az változtathat az alkalmazás állapotán. Azt meg nem tudom, hogy ad vissza értéket?





Ez az egész CQRS új dolog nekem. ASP.NET Core MediatR-rel szeretném megvalósítani. 

(hobbi, tanuló projektről van szó)
Mutasd a teljes hozzászólást!

  • Lehetne ezt Query-ként kezelni és a végén pedig dispatchel egy eventet RefreshTokenCreatedEvent(), ami meg az adatbázisba menti a refresh tokent?
    Mutasd a teljes hozzászólást!
  • Én a helyedben az authentikációt kezelő service-t kiemelném egy önálló egységbe, ami aztán nem CQRS szerint működne. A JWT create/refresh célszerűen egy szinkron művelet, viszont a CQRS alapvetően aszinkron feldolgozásra épít.

    Általánosságban amikor egy művelet megköveteli a szinkron választ, akkor CQRS esetén 2(+1) stratégiád van:
    1) websocket-en keresztül válaszolsz a kliensnek. Előnye, hogy szépen illeszkedik az üzenet alapú architektúrába, hátránya, hogy viszonylag melós egy robosztus szinkronizációs rendszert kiépíteni.
    2) cmd oldali api blokkol és simán válaszol. Egyszerű, viszont ha sok ilyen api-d van, akkor lehet nem a CQRS a megfelelő architektúra a problémádra...
    +1) Az előző gondolatot folytatva, ha alapvetően szinkron válaszokra van berendezkedve a kliensed, akkor a CQRS inkább átok, mint áldás.
    Mutasd a teljes hozzászólást!
  • Eddig service + repository patternnel van megoldva.
    Ezt a CQRS patternt tanulás szempontjából szerettem volna behozni a fent említett helyett. 
    A célom vele pusztán annyi lenne, hogy a controller tömör legyen.
    Mutasd a teljes hozzászólást!
  • A CQRS és a "service + repository" pattern más architektúrális szinten jelennek meg, azaz nem cserélhetőek egymással. A CQRS annyit jelent, hogy más adatmodellt használsz az alkalmazásod adatainak módosításához (command model) és az aktuális állapot lekérdezéséhez (query model). A CQRS ugyan nem rendelkezik arról, hogy ezt a két modellt külön modul szolgálja ki, de a mostani micro service érában érdemes ezeket szétválasztani. Az alapvető ötlet az architektúra mögött, hogy a költséges join/lookup műveleteket rögtön az adat mentésekor végezzük el egy erre a célra kialakított adatmodellbe, így időt spórolhatunk a megjelenítéskor, ergo gyorsabb lesz az alkalmazás a felhasználók számára. A "service + repository" egyszerűen a rétegzett architektúra konyhanyelvi megfogalmazása, amit minden esetben modulon belül használsz. A repository a perzisztált adatmodelled (ami történelmileg jellemzően relációs) és a programod domain modellje (jellemzően OOP) közötti "fordításnak" egy patternje. A service réteg ezt a domain modellt szervezi a view-d számára üzleti szolgáltatásokba.
    Mutasd a teljes hozzászólást!
abcd