Hirdetés

Keresés

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

  • #39560925
    törölt tag

    A JSON generálásra céloztam. És így van, ha adatokat adsz-veszel, akkor több kommunikációval jár, ami hálózati probléma lehet.

    Másik oldalról viszont ott van a fejlesztés és karbantartás. A Java legnagyobb előnye az előtte lévő nyelvekkel/rendszerekkel szemben, hogy gyorsan tudsz eredményt produkálni, pláne ha ilyen irgalmatlan nagy ökoszisztéma jár vele. Ha lábon lövöd magad egy olyan implementációval, amivel időt veszítesz, és rugalmatlanná teszed az alkalmazásodat, és mindezt a hálózati forgalom miatt aggódva, akkor pont a Java előnyeit áldozod be. Néha erre szükség van, amikor nagyon kritikus a teljesítmény egy adott vason, de nem minden áron.

    Tegyük fel, hogy a kommunikáció régebbi MVC-szerű alapokra épül. Oldalak jönnek le sokszor feleslegesen, mire a teljes adatkészletet megkapod. Ha már valami ajaxos megoldást is használsz, akkor az overhead sokkal kisebb lesz; akkor bukik ki a leginkább, amikor egy eseményre több kérést kell lezavarnod. A teljesítmény a hálózat teljesítőképességén, és a protokollon is múlik. Ha viszont már websocket/STOMP klienst használsz, akkor megint eltűnik az overheadből egy elég nagy rész, mert a kapcsolat felépítésének a költsége nem terheli a további requesteket; gyakorlatilag eljutsz odáig, mintha egy ESB/JMS integrációs megoldást használnál, aminek a másik végén egy repository jellegű szolgáltatás ül.

    Szóval ha engem kérdezel, csak magadat szívatod meg a DTO-kkal.

    Megkérdezem a konzulensem erről, hogy legyenek-e wrapper osztályok, vagy külön rest hívásban jöjjenek-e le a kapcsolatok.

  • Aethelstone
    addikt

    A JSON generálásra céloztam. És így van, ha adatokat adsz-veszel, akkor több kommunikációval jár, ami hálózati probléma lehet.

    Másik oldalról viszont ott van a fejlesztés és karbantartás. A Java legnagyobb előnye az előtte lévő nyelvekkel/rendszerekkel szemben, hogy gyorsan tudsz eredményt produkálni, pláne ha ilyen irgalmatlan nagy ökoszisztéma jár vele. Ha lábon lövöd magad egy olyan implementációval, amivel időt veszítesz, és rugalmatlanná teszed az alkalmazásodat, és mindezt a hálózati forgalom miatt aggódva, akkor pont a Java előnyeit áldozod be. Néha erre szükség van, amikor nagyon kritikus a teljesítmény egy adott vason, de nem minden áron.

    Tegyük fel, hogy a kommunikáció régebbi MVC-szerű alapokra épül. Oldalak jönnek le sokszor feleslegesen, mire a teljes adatkészletet megkapod. Ha már valami ajaxos megoldást is használsz, akkor az overhead sokkal kisebb lesz; akkor bukik ki a leginkább, amikor egy eseményre több kérést kell lezavarnod. A teljesítmény a hálózat teljesítőképességén, és a protokollon is múlik. Ha viszont már websocket/STOMP klienst használsz, akkor megint eltűnik az overheadből egy elég nagy rész, mert a kapcsolat felépítésének a költsége nem terheli a további requesteket; gyakorlatilag eljutsz odáig, mintha egy ESB/JMS integrációs megoldást használnál, aminek a másik végén egy repository jellegű szolgáltatás ül.

    Szóval ha engem kérdezel, csak magadat szívatod meg a DTO-kkal.

    Az MVC önmagában egy elavult szar szerintem....ahogy írod is, a felesleges oldalletöltések miatt. Nekünk van még pár MVC-s projektünk, de kimerülnek már a default oldal letöltésében. Minden egyéb forgalom ajax/json kombóval megy.

    A DTO-s okosságnak ott van egyébként értelme, ahol az entitásból kinyerhető adatok és a struktúrájuk valamiért köszönőviszonyban sincs azzal, amit a kliensre le kell zavarni(láttam már ilyet)...másrészről nekem sok GWT-s projektem volt és ott sokáig a DTO design patternt erőltették. Mostanában nem tudom, hogy miként van...2.4-nél leakadtam..

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