Hivatalos a beépített webszerverrel érkező Java 18

Hivatalos a beépített webszerverrel érkező Java 18
2022-03-23T12:03:16+01:00
2022-07-05T18:33:46+02:00
2022-10-17T03:46:07+02:00
  • Ezért is jó, hogy natív SQL-ben tudod hintelni a plannert, hogy melyik indexet használja...

    Tudod, de ritkán jársz jól vele. Általában nem csinál hülyeséget sem az EF kódgenerálója sem a query optimizer. Amikor pedig igen, akkor még mindig ott az SP, amit ugyanúgy használhatsz EF-ben is.
    Mutasd a teljes hozzászólást!
  • Nem értem ezt miért írod le már nem tudom hányadszor. Ráadásul arra a commentemre válaszul, amiben én magam hoztam példát egy elég jelentős átalakításra.

    Amit írsz semmilyen viszonyban nincs azzal, hogy egy generált lekérdezésnél nem sok beleszólásod van, hogy milyen SQL generálódik ki. Amit te írsz SQL-t, azt viszont tudod optimalizálni azokkal az indexekkel, azokon az adatokon, amiken élesben végre lesz hajtva. Hogy ezen is változtat a DB, meg a kigeneráltan is, az nem kérdés. A kérdés az, hogy egy generált query, és egy kézzel írt query planje eltér-e egymástól, és utóbbi esetben mennyivel van nagyobb esélyed olyat írni, ami jobb, mint amit az ORM generál.

    De mindegy is, mert én amúgy se azt mondtam, hogy az ORM (vagy urambocsá az EF) gagyi, hanem hogy a nem triviális lekérdezéseknél van értelme kézzel írt SQL-t használni.

    Csak ezek is kétélű fegyverek, nem is annyira az index karbantartásának a költségei miatt, hanem az új index esetén van hogy más query-k is megváltoztatják a query plan-jüket ami viszont nem biztos hogy jó nekik performancia szempontjából.

    Ezért is jó, hogy natív SQL-ben tudod hintelni a plannert, hogy melyik indexet használja...
    Mutasd a teljes hozzászólást!
  • Egy jo adazbazis infrastrukturanal ennek nem szabadna komoly fejtorest okozzon. Pl. : van(nak) report szerver(ek) es a felhasznalokat kiszolgalo OLTP szerver(ek).
    Mutasd a teljes hozzászólást!
  • Legyen igy. En tenyleg teljesen hulye vagyok C#-hoz.

    Nekem megsem tunt eddig tobbnek eddig, mint egy ovodas "bibiiii, a C# jobb" jateknal.
    Mutasd a teljes hozzászólást!
  • Nálam vannak olyan fejlődési irányok is, hogy először adhock SQL lekérdezésben alakul a lekérdezés. 
    Valamilyen db utillal innen --pl. xls export--, ezt kapja a felhasználó.
    Ha tetszik neki, erre van szüksége, akkor lehet egy formázott PDF report lesz belőle, egyszerű paraméterezéssel (a reportoló utility lehetőségeivel).
    Ha meg nem eseti a dolog, és be kell építeni, akkor bekerül a programba is ez a lekérdezés de jobban támogatott (pl. nem gépelt hanem legördülő menüből választott) ill. további paraméterezéssel.

    De persze van olyan irány is, hogy a rendszer tervezésekor egyértelmű egy report és az ORM rekordszerkezetnek tökéletesen megfelelő, nem valami "csavaros" módon összeszedett adatcsomag kell.
    Mutasd a teljes hozzászólást!
  • Ezzel szemben egy összetett reporthoz az adatok beszerzéséhez az SQL szöveges megoldása tökéletesebb sokszor az ORM-nél.

    Igazából ez sem igaz teljesen. A legtöbb reportnál paraméterek vannak, és ettől függő feltételek.

    Ezt ORM nélkül vagy úgy tudod megoldani, hogy stringben tákolod össze a feltételedet - ami egy jó forrása a bugoknak, de ha nem jól csinálod akkor akár a biztonsági réseknek is, és végül is a kereket találod fel vele - vagy fix feltételeket írsz Pl. egy SP-be, valahogy úgy hogy (@p1 is null) or (x.Field>@p1), csak ez meg lassú tud lenni, ugyanis az SQL szerver a feltétel mindkét tagját lefuttatja ilyenkor, nem áll meg az elsőnél csak mert ez hamis. Ami egy szimpla relációnál nem feltétlenül gond, de egy exists már tud vicces lenni.
    Mutasd a teljes hozzászólást!
  • Igazából a legenerált kód _nagyon_ el tud térni az általad leírt SQL-tõl. Tényleg érdemes egyszer megnézni egy komplexebb MS-SQL lekérdezést és a belőle generált query plan-t. A különbségek ott kezdődnek, hogy melyik táblákból indulnak el a lekérdezések, miket olvas végig szekvenciálisan és szűr rá, miket keres ki hozzá kulcs alapján, hol mit merge-el, stb.  Ez fogja igazából meghatározni a sebességet, és bizony ez elég magasról tesz arra hogy te formailag ezt hogy írtad le. Az optimizer maga hozza a döntéseket az indexek és az ő statisztikáik alapján. És ezeket - hacsak nem írsz nagyon furmányos tárolt eljárásokat - igazából az indexekkel lehet befolyásolni. Csak ezek is kétélű fegyverek, nem is annyira az index karbantartásának a költségei miatt, hanem az új index esetén van hogy más query-k is megváltoztatják a query plan-jüket ami viszont nem biztos hogy jó nekik performancia szempontjából. De igazából ezek a tapasztalataim 2008-as SQL szerverre vonatkoznak, azon csináltam ezt a mókát elég sokat, és annak is volt már vagy 5-6 éve, de ahogy nézem ez azóta is inkább a még nagyobb automatizálódás irányába ment (Pl. az azure SQL már maga javasolja a szükséges indexeket).
    Mutasd a teljes hozzászólást!
  • Ezek jó részét nem én mondtam, csak azt vágd a fejemhez légyszi, amiről én tehetek :)

    Ok, akkor összeszedem, mit mondtam a propertyről:

    - Ugyanaz a funkciója, mint a getter-setter-nek javában. Funkciót tekintve ekvivalensek.
    - Nyelvi elem konvenció helyett.
    - Nyelvi elemként biztonságos mechanizmusok épülhetnek rá, pl. kódgenerátorok, serializerek, ORM. 
    - Nyelvi elemként összhangban van más nyelvi elemekkel, pl. az async-kal, vagy a recorddal.
    - Konvenció szerint jól megkülönböztethető a field-től, így kapsz egy "másik fajta" field-szerű nyelvi elemet: Jól használva javítja a kód karbantarthatóságát.
    - Debugger előnyök: Ki tudja értékelni a property-t a debugger anélkül, hogy átlépnél rajta

    (Most mondom, hogy C#-ban sem kötelező a setter megírása a propertynel, és erre törekszünk is természetesen)

    Nincsen hátránya a getter-setterhez képest, ehhez képest elhangzott, hogy bonyolítja a nyelvet (gazdagítja, nem ugyanan az), felesleges (dehogy, az előnyei jól kihasználhatók), és hogy azért nincs a javaban, mert <insert nyelvi stratégia bullshit>, mint végső érv.
    Mutasd a teljes hozzászólást!
  • Lehet, hogy rosszul figyeltem meg, de miutan kitargytaltuk 3x-4x, hogy C#-ban is van set/get, csak ennek elfedesere meg be van vezetve a property es mindekozben ugyanennyiszer kitargyaltuk, hogy java-ban is van set, de ahol lehet a torekves megvan ennek a "nem hasznalatara". Tehat nemhogy extra property, de set sincs hasznalva. Tenyleg nem tudom, hogy a C# ezt hogyan oldja meg belul, de nekem ez 2 extra lepesnek tunik, egy mezo beallitasara. De mindez vegytiszta takolmany, mert ezek szerint nem a set "nem hasznalata" a megoldas, hanem a set elfedese valami extraval, pl property. Ez volt az a pont, ahol nem tudtam eldonteni, hogy lehet-e ez a beszelgetes abszurdabb.
    A tobbi mar csak adalek volt, hogy Java-ban se await, se ez, se az, a lambda sem sikerult olyan jol, a hibernate sem ugyan az, mert setter kell hozza (pedig nem kell, persze C#-ban nem kell, csak property, ami majd hasznalja a set-et...ha jol ertem a mukodest), nem beszelve a HQL-rol, amiben csak string-eket lehet konkatenalni. Mar fel sem tudom idezni mennyi minden hangzott el, csak fogast lehessen talalni. Mar csak azt hianyoltam a legvegen, hogy vajon ki fogja bedobni, hogy a C# jobban optimalizalt sql-t kop ki magabol, mint a Java, hibernate teren, es meg ha ez igy is lenne, nem tudom kinek szamit ez.
    En mar hasznaltam MyBatis-t, JOOQ-t, Spring JdbcTemplate-et, Hibernate-et es meg mittudomen mar mit az elmult 15 evben, de meg eszembe nem jutott ezeknek a versenyeztetesere. 
    Mindekozben tobbszor elmondtuk, hogy a C# egy jo nyelv, ez persze nem volt eleg. Bar en biztosan nem ertek hozza es egyaltalan nem kovetem mi zajlik azon a teren.
    Valamint azt sem ertem, hogy tenyleg elhiszitek-e, hogy valami meroben mast csinaltok, mintha Java-znatok es nem tunik fel, hogy az eszkoz egy picit mas, de sem nem jobb sem nem rosszabb, ez mar csak a velemeny hozzaadasa.

    Azt is tudom, hogy ez nem mind toled jott, de mar jo ideje nem ertem, hogy mi tortenik, oszinten.
    Mutasd a teljes hozzászólást!
  • Ha valakinek a kijelentéseire reagálsz, akkor legalább idézd, vagy valahogy hivatkozz rá, hogy tudja miről van szó. De semmilyen megalapozatlan kijelentést nem tettem. A sokadik "tudja-e", "miért nem úgy tudja, ahogy én szoktam csinálni", "tákolás" commentekre hoztam a sokadik példát, ellenpéldát, magyarázatot.

    Az én "megalapozatlan" kijelentésem ez volt, amire reagáltál:

    Sok helyen hasznos egy ORM, de egy nem triviális lekérdezésnél nem egy előnye van, ha SQL kifejezés, vagy SQL-lé nagyon könnyen átalakítható hívási lánc (lásd ismét JOOQ) van a kezedben.

    Nem megalapozatlan kijelentésekre reagálsz, hanem újra és újra előveszed a C# akármit, hogy mert nézzük meg az mit tud. Az előbbire pl ezt találtad írni: 

    Természetesen tudod használni JOOQ-szerűen az EntityFramework-öt. De mondjuk nem tudom mennyire lesz elegáns a JOOQ megoldás, ha kapcsolódó rekordokat akarsz betölteni több lépésben.

    A kutya nem beszélt az EF-ről, és tök irreleváns, hogy lehet-e JOOQ-szerűen használni (bármit is jelentsen ez). Majd jött a problémafelvetés, hogy tudja-e, amit tud-e.

    Még egyszer, nekem semmi bajom a Javaval, természetesen.

    Elhiszem. Nincs semmi bajod a Javaval, csak lépten-nyomon leírod, hogy bezzeg a C#-os megoldások :)
    Mutasd a teljes hozzászólást!
  • Nem. Volt egy probléma, adtak rá megoldást (pl. EF) és mivel működik így szeretjük :)
    Mutasd a teljes hozzászólást!
  • Még egyszer, nekem semmi bajom a Javaval, természetesen. A megalapozatlan kijelentéseidre reagáltam csak.
    Mutasd a teljes hozzászólást!
  • Ezt is ertem.
    Csak mar kezdem ugy erezni, hogy barmit mondunk, azt takolas :)
    Mutasd a teljes hozzászólást!
  • Kar native SQL kodot irni?


    Mindent a helyén kezelni.
    Nálam egy összetett GUI adatbevitelben (master-detail, relációs kódok-rekordok) kész áldás az EF (vagyis egy fejlett ORM).

    Ugye a beolvasás utáni állapot módosulhat. (Masterben és detailban is kódok-relációs adatok).
    A detail-ban insert/delete.
    Új kód-relációs adatok.
    Eredetileg beolvasott, utólag hozzáolvasott, újonnan beszúrt detail ill. relációs rekordok.
    Az összes adatot összedobni egy halmazba, és a végén csak annyit mondani "írd vissza"... a sorrendekre, függőségekre meg nem kell figyelni, oldja meg. :)
    Itt nincs helye SQL text-nek, primitív sql parancsokat generál az ORM, a függőségek figyelését meg megoldja maga.

    Ezzel szemben egy összetett reporthoz az adatok beszerzéséhez az SQL szöveges megoldása tökéletesebb sokszor az ORM-nél.
    Mutasd a teljes hozzászólást!
  • Ennek a generálásánál elég kis mértékben veszi figyelembe, hogy te mit hogyan joinolsz, legalábbis formailag.

    De, nagyonis figyelembe veszi. Az optimalizáció a relációs algebra szabályai szerint történhet, kiindulva a lefuttatni kívánt lekérdezés által definiált műveletekből. Az optimizer nem érti, hogy mit akarsz lekérdezni, hanem szabályok mentén transzformációkat végez, és matematikai műveleteket cserél hatékonyabb matematikai műveletekre. Az egész az általad leírt lekérdezésből indul ki. Hogy azt a végtelenségig meg tudja változtatni, az egy tök másik dolog. Nálunk pl a "select * from foo where bar=?" lekérdezés lefordul egy ".getMap("foo").get()" típusú API hívásra, és az optimizer jó részét át tudja ugrani. De nem kis mértékben veszi figyelembe a queryt, hanem pont azt alakítja át.

    És pesze vannak dolgok amiben az ORM nem annyira jó, Pl. mass update egy mezőre az egész táblán.

    Mert ez semennyire nem ORM feladat. Cserébe minden ORM-ben van erre hatékony megoldás. Gondolom EF-ben is. 

    De igen, szerintem átalában egy mezei select-join párosnál nem sok hozzáadott értéke van annak, ha kézzel írod az SQL-t.

    Kérdés, hogy mi a hozzáadott értéke ORM-ben leírni ugyanazt :) Egy CRUD lekérdezésnél tökmindegy miben írod, arra megbízhatóan jó lekérdezést fog generálni bármilyen mapping tool (ahogy említve lett, még a JOOQ is). A kérdés a trükkösebb lekérdezésekkel van.
    Mutasd a teljes hozzászólást!
  • Most tényleg arról akarsz meggyőzni, hogy egy join/exists/in/or közül a megfelelőt kiválasztani egy akkora rocket science? Illetve ahol ez tényleg nem triviális, és ahol te kézzel tudod optimalizálni a lekérdezést a plannek megfelelően, ott majd pont az ORM fog jobb lekérdezést generálni? 

    És csak úgy miheztartás végett: már istentudja hány hozzászólás óta egy Java-s cikk alatt írogatjátok, hogy a property, a LINQ, és úgy minden mennyivel f@szább C#-ban, mint bármi a Javaban. A jóégtudja, hogy milyen indíttatásból. A JOOQ-ot arra hoztam példának, hogy lehet typesafe (a Sting által írt keretek között), jól olvasható, egyszerűen portolható, jó teljesítményű lekérdezéseket írni Javaban is. Minden elhangzott ellenpélda arról szól, hogy az állítottakkal ellentétben mennyire simán lehet megoldani mindent Javaban is, amitől el vagytok ájulva a C#-ban. Legtöbb esetben a nyelv megváltoztatása nélkül. Vagy ha a nyelv megváltoztatásával, akkor máshogy is meg lehet oldani ugyanazt, mint ahogy a C# tette. Akár még jobban is, lásd pl record, virtual threadek. 

    Hogy lassan arra futunk ki, hogy nem mindenki érti mi is az a lambda, hogy a LINQ nyelvi elemségén kívül gyakorlatilag minden megvan belőle Javaban is (csak kicsit máshogy kell ugyanazt leírni), hogy mi a hátránya (meg ha már, akkor mi az előnye, ami el se hangzott) az async/await-nek a virtual threadhez képest, miért van erőltetve egyre inkább az immutability, és mi a gond a setterrel koncepcionálisan stb, kezd elég furává válni ez a szál ezeknek a "C#-ban ez mennyivel jobb" panelek repetitív emlegetésétől.

    Nem tökmindegy nektek, hogy mi van a Java világban, ha úgyse abban dolgoztok? :)
    Mutasd a teljes hozzászólást!
  • Általában nem. Bizonyos esetekben lehet az SQL kód bottleneck, de ott már nem fogod egy mezei joinnal vagy where feltétellel megúszni, ott általában SP-t kell írni rá. De jó eséllyel előbb fogsz átgondolt tábla struktúrával és ésszel létrehozott indexekkel performancia növekedést elérni. Meg partícionálással meg sok mindennel, ez egy elég sokrétű történet. De igen, szerintem átalában egy mezei select-join párosnál nem sok hozzáadott értéke van annak, ha kézzel írod az SQL-t. A másik oldalon persze az SQL-t sem lehet elfelejteni, mert van olyan eset amikor viszont tényleg kell.
    Mutasd a teljes hozzászólást!
  • Vagy pl tök máshogy kell joinolni, mint ahogy a query generátorod feltételezi, hogy szerinte jó lesz.

    Az a baj, hogy legalábbis MS-SQL-nél a te általad írt SQL mondatból egy elég komplex programot ír a query optimizer (de szerintem kb. ugyanez van minden komolyabb szervernél). Ami már két joinnál is csak nagyon-nagyon messze lesz attól amit te eredetileg leírtál.

    Valami ilyesmit fogsz látni.

    Ennek a generálásánál elég kis mértékben veszi figyelembe, hogy te mit hogyan joinolsz, legalábbis formailag. Tartalmilag mondjuk egy CTE esetleg tud vicces dolgokat csinálni, a régi EF-ekben voltak is ilyen gondok, de őszintén szólva nekem az elmúlt években nem igazán volt gondom az EF által generált querykkel performancia szempontból. Az EF-nél inkább a bulk műveletek környékén volt eddig gondom, Pl. ha sok entitást kellett egyszerre létrehozni. És pesze vannak dolgok amiben az ORM nem annyira jó, Pl. mass update egy mezőre az egész táblán.
    Mutasd a teljes hozzászólást!
  • A JOOQ az database first szemlélettel dolgozik, míg az ORM-ek code first szemlélettel. Nálam ezzel lazán  a JOOQ a győztes.

    JOOQ-ban is van igen erős mapping tudás, simán lehet egyelen SQL paranccsal kompelx DTO (apa-több gyerek kapcsolatt) listát létrehozni.

    JOOQ-ban sem natív SQL-t definilász, hanem egy nagyon SQL szabvány közeli dialektust. Majd runtime generál ez alapján az adatbázisnak megfelelő natív SQL-t.
    Mutasd a teljes hozzászólást!
  • Akkor osszefoglalva itt mi a lenyeg? Kar native SQL kodot irni?
    Mutasd a teljes hozzászólást!
  • 2 jellemzője miatt hoztam ezt a példát:

    - kevéssé érzékeny a execution plan-re
    - az összegyűlt knowhow pont bele lehet tenni egy library-ba.

    Míg a JOOQ-s megoldással mindig fel kell találni a kereket. Szóval ez egy példa arra, amikor az EF jellegű ORM-nek előnye van a JOOQ-s megoldásokkal szemben. (Más területen meg hátránya, nyilván, csak ne hozzuk már ki egyértelmű győztesnek a JOOQ megközelítést.)
    Mutasd a teljes hozzászólást!
  • Így már értem, csak elsőre fordítva tetted fel a kérdést. A magadra utaltságot viszont nem értem. Ha azt jelenti, hogy meg kell írnod az SQL-t, akkor igen. Ha SQL-eket írsz, akkor neked kell megírni az SQL-t. Amit felhoztál, az egy ORM-nél klasszikus probléma, ha lazy fetch-el, és egyenként gyárt queryket, vagy akár batchben. Eager fetchnél emlékeim szerint a Hibernate is megoldotta. A JOOQ viszont nem egy ORM. Értelemszerűen úgy fog leválogatni, ahogy megírod a queryt.

    Ha esetleg azt akartad volna mondani, hogy az EF (vagy bármi ORM) majd kioptimalizálja valakinek a lekérdezést, aki nem érti annyira az SQL-t, hogy ezt megírja magának, akkor meg inkább nem is akarom érteni a kérdést :)
    Mutasd a teljes hozzászólást!
  • Nézd a linket. Ez egy nem triviális probléma, főleg, ha kapcsolódó entitás láncokat akarsz betölteni, pedig nagyon gyakran kell. Ezt pl. az EF elegánsan megoldja, JOOQ-val meg magadra vagy utalva.
    Mutasd a teljes hozzászólást!
  • Nem egészen értelek. Amiről én beszéltem az egy SQL kifejezés. Aztán a result setet meg úgy dolgozod fel, ahogy akarod.
    Mutasd a teljes hozzászólást!
  • Inkább az 1-N probléma megoldási módjaira lettem volna kíváncsi.
    (erre: ID Lists Aren’t the Best Solution for the N+1 Problem )
    Mutasd a teljes hozzászólást!
  • A JOOQ csak egy példa volt. Mondhattam volna egy valamilyen batist, vagy akármit, ami pont ugyanazt tudja, mint egy SQL kifejezés (mivelhogy valójában az). A kapcsolódó rekordokat meg betöltöd a result setet streamelve. Ahogy LINQ-ben is csinálod amúgy (gondolom erre futtattad volna ki).
    Mutasd a teljes hozzászólást!
  • Természetesen tudod használni JOOQ-szerűen az EntityFramework-öt. De mondjuk nem tudom mennyire lesz elegáns a JOOQ megoldás, ha kapcsolódó rekordokat akarsz betölteni több lépésben.
    Mutasd a teljes hozzászólást!
  • De általában véve, ha egy ma SQL szervernél lassú a végeredmény, akkor vagy az adatszerkezeted rossz, vagy hiányzik valami index, vagy hülyeséget kérdeztél a szervertől.

    Vagy pl tök máshogy kell joinolni, mint ahogy a query generátorod feltételezi, hogy szerinte jó lesz. Nem egy olyan lekérdezéssel volt dolgom, amit átalakítva sokkal gyorsabb lett a lekérdezés. Indexek hozzáadása nélkül, ami ugye írásnál nagyon nem mindegy. Tökjó, hogy az optimizer optimalizál, de csak azt tudja optimalizálni, amit te adsz neki. Kicsit egyszerűbb dolgod lesz SQL-ben reprodukálni a plan alapján módosított optimális SQL queryt, mint egy akármilyen ORM aktuális generátorán keresztül (ez mindkét irányban igaz).

    Sok helyen hasznos egy ORM, de egy nem triviális lekérdezésnél nem egy előnye van, ha SQL kifejezés, vagy SQL-lé nagyon könnyen átalakítható hívási lánc (lásd ismét JOOQ) van a kezedben.
    Mutasd a teljes hozzászólást!
  • Úgyhogy tegyünk elé még egy réteget, ami még a lekérdezést is kiveszi a kezünkből. Majd rakjunk rá még indexeket, csak azért, hogy a kigenerált query normálisan fusson le (ha egyáltalán ez megoldja persze).

    A probléma ott kezdõdik, hogy az SQL belül így is, úgy is kb. úgy fut le ahogy a query optimizer jónak látja. Te elképzelheted a kis kézzel szépen összetákolt SQL mondatodban hogy te ezt joinolod azzal a táblával, aztán ezt egy másikkal, aztán egy exists, stb. aztán amikor megnézed az executed query plan-t akkor látod hogy ez bizony nem is hasonlít arra, amit te elképzeltél - néha meglepően másképp szedi elő az adatokat mint ahogy azt vártad volna. Ezért nem nagyon érdemes nagyon napi szinten a kigenerált querykkel törpölni, max. nagyon extrém esetben. De az ilyen extrém esetek nagy részében is vagy egy index lesz a megoldás (mert akárhogy is írod át a query-t akár kézzel is, az optimizer úgy dönt ahogy jónak látja - és szinte mindig igaza van) vagy tárolt eljárás, olyan ronda trükkökkel mint a temp táblák.

    De általában véve, ha egy ma SQL szervernél lassú a végeredmény, akkor vagy az adatszerkezeted rossz, vagy hiányzik valami index, vagy hülyeséget kérdeztél a szervertől.
    Mutasd a teljes hozzászólást!
  • Szerintem tobb mint 10 eve lattam utoljara

    Én se mostanában láttam. Igaz már évek óta semmi olyannal nem dolgozom, amihez bármi ilyesmi kéne, úgyhogy ez nem jelent sokat. Anno viszont használtam komplex keresőformokból dinamikus lekérdezés generálására. Ott azért van létjogosultsága.

    Amit a LINQ tud, hogy magába a nyelvbe integráltak egy SQL-szerű másik nyelvet, amivel így keverten kifejezéssel és API-val tudsz dinamikus lekérdezéseket gyártani: Linq: adding conditions to the where clause conditionally

    Pont annyira transzparens mint a Criteria API, és komplex esetben pont annyira elveszíti az áttekinthetőségét. De ez a feladatba van kódolva. Bármilyen megoldással ír is az ember komplex dinamikus lekérdezést, egy bizonyos méret felett nehezen áttekinthetővé válik a sok if miatt. Azzal lehet kicsit segíteni, ha metódusokba kiszervezésre kerülnek a dinamikus részek, hogy maga a felépítés áttekinthetőbb legyen. Onnantól viszont kis túlzással tökmindegy, hogy belül hogy van leírva maga a lekérdezés. A szűk keresztmetszet úgyis a tesztelés lesz az ifek lehetséges kombinációi, és így a where clause-ok, joinok stb magas száma miatt. Ebben semennyire nem segít semmilyen ORM, API nyelvi szintre emelése stb sem. 

    Egyszerűbb esetben meg úgyse ilyen bonyolult API-val támad az ember. Ilyen szempontból is klassz egyébként a JOOQ, mert az egyszerű, és a dinamikus esetre is ugyanaz az API.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd