Hirdetés

  2. Fórumok
  3. Szoftverfejlesztés
  4. Java programozás
  5. (kiemelt téma)

Hirdetés

100 000 érv a ReGalaxy mellett: Vásárolj Galaxy Z Fold7 I Z Flip7 vagy Galaxy S25 szériás készüléket, és régi mobilod felújítását 100 000 Ft-ig mi álljuk!

Új hozzászólás Aktív témák

  • #11098 floatr veterán mobal #11097
    Új Válasz #11098
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    floatr

    veterán

    válasz mobal #11097 üzenetére

    A legjobban az tetszik, hogy a sonar oldalán lévő leírás és javaslat is tele van agyatlan anti-patternekkel. Sajnos a sonar tele van hülyeséggel, nem véletlen, hogy meghagyták a lehetőségét annak, hogy kikapcsolj egy-egy szabályt ;)

    Ha DTO-kat gyártasz akár rétegenként, akár microservice-enként, akkor plusz konverziós lépéseket teszel a kódba potenciális hibaforrásokként. A leggyakoribb az, amikor egy fejlesztő erre rá van kényszerítve, hogy gépiesen átdobálja az adatokat, néha konvertál típusok közt. Komplexebb lesz a kód, és semmi nem teszi biztonságossá abban az irányban, amit a sonar szabályban és a linkjeiben -- leginkább csak -- sugallnak. A mintakód félrevezetően gyatra, hűen tükrözi a témakörben gyakori ultragagyi minimalista tutorialok szellemét. Nem ment semmi és senki automatikusan, ellenőrizetlenül, validáció, autentikáció és access control nélkül, pláne nem a Controllerből, ha publikus endpointról van szó. Ha microservice-eket használunk, akkor meg egyenesen hiba eltakarni egy újabb réteggel az adatokat pl az api gateway elől. Hasonló okokból teljesen feleslegesnek tartom az OpenSessionInView filterrel kapcsolatos felindulásokat.

    A leggyakoribb érdemi oka annak, hogy DTO-t vagy projekciót kell használni, az szokott lenni, hogy teljesítménybeli optimalizációt kell csinálni, így bizonyos lekérdezéseket view-ra specializáltan kell implementálni, vagy mert a frontend nem tud mihez kezdeni összetett adatokkal. Esetleg az api gateway összegyúr két service-ből származó adatot, de az meg szvsz tervezési hiba, ha erre kényszerült rá valaki.

    Egy esetben látom még a létjogosultságát a DTO-szerű képződményeknek, ha az Entity/Document bloated lenne egyébként. Ez meg szubjektív.

    Nem kell, hogy egyetértsünk, de a dogmatikus kijelentések teszik tönkre a szakmát.

Új hozzászólás Aktív témák