abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 13:55 | Zajímavý projekt

UPSat je první open source nanodružice. Jedná se o společný projekt nadace Libre Space Foundation a University of Patras. Repozitáře projektu jsou k dispozici na GitHubu. Pod Libre Space Foundation patří také projekt SatNOGS (zprávička), projekt globální sítě open source pozemních satelitních stanic, vítězný projekt soutěže The Hackaday Prize 2014. UPSat je součástí mise QB50 (Twitter). ID UPSatu je GR02. GPS přijímač na UPSatu je od české společnosti SkyFox Labs. Součástí mise QB50 je i česká nanodružice VZLUSAT-1 s ID CZ02.

Ladislav Hagara | Komentářů: 0
21.4. 15:00 | Komunita

V diskusním listu Thunderbird planning vývojáři poštovního klienta Thunderbird řeší, zda by nebylo možné budoucí Thunderbird postavit nad webovými technologiemi, tj. nad Electronem, stejně jako například Nylas Mail. Gecko, nad kterým je Thunderbird postaven, se má hodně změnit. V plánu je odstranění vlastností, které Firefox už nepotřebuje, ale Thunderbird je na nich závislý [Hacker News, reddit].

Ladislav Hagara | Komentářů: 74
21.4. 10:22 | Bezpečnostní upozornění

Společnost Oracle vydala čtvrtletní bezpečnostní aktualizaci svých softwarových produktů (CPU, Critical Patch Update). Opraveno bylo celkově 299 bezpečnostních chyb. V Oracle Java SE je například opraveno 8 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 7 z nich. V Oracle MySQL je opraveno 39 bezpečnostních chyb. Vzdáleně zneužitelných bez autentizace je 11 z nich.

Ladislav Hagara | Komentářů: 6
21.4. 10:00 | Pozvánky

V úterý 25. dubna proběhne další Prague Containers Meetup. Přijďte se nechat inspirovat jak zlepšit build/delivery pipeline vašich kontejnerových aplikací.

little-drunk-jesus | Komentářů: 2
20.4. 21:33 | Komunita

Na Launchpadu se objevilo kódové jméno následující verze Ubuntu. Ubuntu 17.10 bude Artful Aardvark (mazaný hrabáč) [OMG! Ubuntu!].

Ladislav Hagara | Komentářů: 9
20.4. 20:11 | Zajímavý software

MojeFedora.cz informuje, že společnost Nylas oznámila vydání verze 2.0 poštovního klienta Nylas Mail (původně Nylas N1), která již plně podporuje Linux. Obchodní model společnosti je tzv. open core. Samotný klient je open source, ale uživatel si musí připlatit za některé pokročilé funkce. V základu se lze připojit k GMailu nebo libovolnému účtu přes IMAP. Podpora Exchange je pouze v placené verzi. Klient je napsaný nad Electronem.

Ladislav Hagara | Komentářů: 12
20.4. 15:55 | Zajímavý článek

České centrum pro investigativní žurnalistiku (ČCIŽ) publikovalo na svých stránkách článek s názvem Je česká státní správa „rukojmím Microsoftu“?. Drtivá většina české veřejné správy je závislá na výrobcích softwarového gigantu Microsoft – a nijak zvlášť jí to nevadí.

Ladislav Hagara | Komentářů: 16
20.4. 02:48 | Nová verze

Google Chrome 58 byl prohlášen za stabilní. Nejnovější stabilní verze 58.0.3029.81 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo 29 bezpečnostních chyb. Mezi nimi i chyba umožňující phishing s unicode doménami.

Ladislav Hagara | Komentářů: 0
19.4. 22:44 | Nová verze

Po šesti týdnech od vydání verze 52.0 byla vydána verze 53.0 webového prohlížeče Mozilla Firefox. Z novinek lze upozornit například na nové kompaktní vzhledy – tmavý z Firefoxu Developer Edition a jeho světlá varianta. Na Linuxu byla ukončena podpora procesorů starších než Pentium 4 a AMD Opteron. Podrobné informace v poznámkách k vydání a na stránce věnované vývojářům. Řešeny jsou také bezpečnostní chyby.

Ladislav Hagara | Komentářů: 11
19.4. 17:44 | IT novinky

Realtimová strategická počítačová hra StarCraft a její rozšíření StarCraft: Brood War jsou ode dneška zdarma. Společnost Blizzard Entertainment chystá remasterovanou verzi (YouTube) a při té příležitosti se rozhodla neremasterovanou verzi aktualizovat a dát ji ode dneška k dispozici zdarma. Hru lze na Linuxu hrát pod Wine.

Ladislav Hagara | Komentářů: 3
Chystáte se pořídit CPU AMD Ryzen?
 (4%)
 (35%)
 (0%)
 (7%)
 (45%)
 (9%)
Celkem 268 hlasů
 Komentářů: 31, poslední 20.4. 21:26
    Rozcestník

    Dotaz: Java 8 - Data Access vs. Entity Framework

    Max avatar 16.4.2015 09:15 Max | skóre: 65 | blog: Max_Devaine
    Java 8 - Data Access vs. Entity Framework
    Přečteno: 905×
    Ahoj,
    měl bych jeden amatérský dotaz (nejsem programátor).
    V jobu máme Oracle db a začíná se pomalu programovat pod C#. Aby se ulehčila komunikace s DB, tak se využívá Entity Framework (EF). Vypadá to pomale, i když novější verze EF mají mít výkonností vylepšení. Pro větší akce se to zdá nepoužitelné (rozdíly jsou v sekundách). Navíc vždy s novější verzí EF se musí čekat, až Oracle vydá aktualizaci svého ODAC pro novější EF. Další problém je, že dost verzí EF bylo mezi sebou nekompatibilních, takže přechodu na novější verzi následoval částečný přepis.
    Narazil jsem na zajímavé info o Java a revolučnímu databázovému přístupu, viz :
    Java 8 Will Revolutionize Database Access
    + tento výkřik :
    Does Java 8 Still Need LINQ? Or is it Better than LINQ?
    Na první pohled vypadá v jave 8 práce s SQL podobně jako v Entity Frameworku. Zajímalo by mně, zda to někdo nepoužíváte a jak je to rychlé? Když se na to dívám okem laika, tak mi přijde, že java 8 má v tomto nemalý náskok.
    Díky
    Zdar Max
    Měl jsem sen ... :(

    Řešení dotazu:


    Odpovědi

    16.4.2015 10:23 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Vypadá to pomale, i když novější verze EF mají mít výkonností vylepšení.
    V jakém smyslu? Že trvá, než EF vygeneruje SQL dotaz, nebo že vygenerované SQL dotazy jsou neefektivní a ručně by je šlo napsat lépe?
    Když se na to dívám okem laika, tak mi přijde, že java 8 má v tomto nemalý náskok.
    V principu nevidím žádný rozdíl. Co vám přijde tak dobré?

    Nicméně s typovou bezpečností na tom bude hůře jOOQ, naráží totiž na omezenost Javy – např. na absenci anonymních záznamů, takže následující dotaz
    Result<Record3<String, String, String>> result =
    create.select(BOOK.TITLE, AUTHOR.FIRST_NAME, AUTHOR.LAST_NAME)
          .from(BOOK)
          .join(AUTHOR)
          .on(BOOK.AUTHOR_ID.equal(AUTHOR.ID))
          .where(BOOK.PUBLISHED_IN.equal(1948))
          .fetch();
    
    vrací trojice, kde k prvkům přistupujete buď pomocí getValue např.
    r.getValue(AUTHOR.FIRST_NAME)
    Jenže, co když se zeptáte na pole, které není součástí výsledku? Dostanete výjimku IllegalArgumentException. Proto je tu druhá možnost – přístup přes pozici
    r.value2()
    Jenže, co když někdo například změní pozici autorova jména? Navíc, pokud bude výsledek obsahovat více než 4 sloupce, bude takový kód těžko čitelný.

    Na druhé straně v C# můžete vytvořit nový anonymní typ
    new { BookTitle = ..., AuthorFirstName = ..., AuthorLastName = ... }
    
    a pak jednoduše psát
    r.AuthorFirstName
    
    a kód je přehledný a bezpečný (kompilátor zachytí, když napíšete r.Year, kde Year není součást výsledku).
    16.4.2015 10:55 Ivan
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Tak jsem koukal na ten Jinq. Jestli to to dobre chapu tak oni vytvori lambda, zkoupiluji ji do bytecode, pak ten bytecode zanalyzuji a vytori z nej SELECT. A to vsechno jenom proto, aby se programatori nemuseli ucit SQL? No prominte mi ten flame, ale jejich starosti bych chtel mit.

    Pokud mate problem s vykonem tak nakonec vzdycky skoncite u SQL a exekucnich planu, s tim ne neda nic delat. Z toho co jsem za vsechny to roky videl, tak castejsi problem je v tom, ze tyhle frameworky nepodporuji producer-consumer design pattern, a tak tahaji kazdy zaznam zvlast, takze to nakonec nedrhne na vykonu databaze, ale mnozstvi round-tripu mezi klientem a databazi. Objektovy pristup se da tezko napasovat na davkove zpracovani dat v SQL.

    Docela by me zajimalo jak se ten Jinq da pouzit na inicialzaci, nejaky komplexnejsi hierarchie trid. (Zvlast kdyz JDBC podporuje pouze skalarni datove typy).

    16.4.2015 11:07 Marek
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    +1, pokud nekdo vazne resi vykon, pak nema smysl nic jineho nez optimalizovany SQL dotaz
    16.4.2015 11:22 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    A to vsechno jenom proto, aby se programatori nemuseli ucit SQL?
    Obecné výhody nástrojů tohoto typu: Kusy dotazů jde používat opakovaně (fragment dotazu jde použít ve více dotazech), nevzniká problém SQL injection, můžete používat stejný dotaz pro databázi, pro kolekce aj.

    Jazyky se silnějšími typovými systémy pak umožňují dotazy parametrizovat tabulkami, názvy polí apod. Například můžete vytvořit typově bezpečné administrační rozhraní, které funguje pro libovolnou tabulku. Pak ho použijete:
    (* Deklarace tabulky. *)
    table t1 : {Id : int, A : int, B : string, C : float, D : bool}
      PRIMARY KEY Id
    
    (* Vytvoříme administrační rozhraní pro tabulku t1. *)
    open Crud.Make(struct
                       val tab = t1
                                 
                       (* Titulek stránky. *)
                       val title = "Crud1"
                                   
                       (* Typy a názvy sloupců. *)
                       val cols = {A = Crud.int "A",
                                   B = Crud.string "B",
                                   C = Crud.float "C",
                                   D = Crud.bool "D"}
                   end)
    
    16.4.2015 15:59 Filip Jirsák
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Odolnost proti SQL injection není výhoda těchto nástrojů, je to standard. Naopak se bohužel stále ještě používají nástroje, které k SQL injection přímo vedou. Výhoda stejného dotazu pro databázi jako pro kolekce mi připadá trochu zvláštní, pokud někdo ty dotazy pouští nad kolekcemi, asi nepotřebuje SQL databázi. Obecně mi tyhle nástroje na vytváření SQL dotazů připadají jako narovnáky na vohejbáky.
    16.4.2015 17:17 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    pokud někdo ty dotazy pouští nad kolekcemi, asi nepotřebuje SQL databázi
    Kolekce se hodí třeba v testech. Nebo má data v databázi a pak ještě v nějaké službě přístupná třeba přes OData. Všude může používat stejné dotazy.

    16.4.2015 17:18 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Nebo má kolekci, která funguje jako cache.
    16.4.2015 20:06 Filip Jirsák
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    A ve všech těchto případech asi nepotřebuje SQL databázi, protože v SQL databázi bude mít nejspíš spousty tabulek provázaných přes identifikátory, zatímco v kolekci bude mít záznamy jednoho typu, ze kterých bude podle nějakých kritérií vybírat. Ano, SQL databáze se dá použít i k uložení takové kolekce, ale je to okrajový případ, a především pozůstatek doby, kdy se data dala v zásadě uložit buď do souboru nebo do SQL databáze. Nepřipadá mi ale šťastné pro takové okrajové řešení vytvářet speciální frameworky.

    Stručně řečeno, tenhle typ ORM nástrojů se hodí tam, kde se jako technologie chybně zvolila SQL databáze.
    16.4.2015 21:04 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Stručně řečeno, tenhle typ ORM nástrojů se hodí tam, kde se jako technologie chybně zvolila SQL databáze.
    To vůbec nemusí být ORM (sám nejsem příznivcem ORM), zmínil jsem třeba Ur/Web – tam jde primárně o korektnost a redukci kódu. Navíc tam nejsou žádné objekty.

    SQL je beztypový jazyk a korektnost kódu vám staticky nepohlídá. Rovněž je tam těžké kód použít opakovaně. Proto je vhodnější použít jiný jazyk.
    17.4.2015 08:34 Filip Jirsák
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Vhodnější by to bylo, pokud by tím jazykem mluvil přímo databázový server.

    Tyhle nástroje sice mohou pohlídat, že vytvoří syntakticky správné SQL, ale to neříká vůbec nic o tom, zda ten SQL příkaz půjde opravdu spustit. Za největší problém považuju to, že ty nástroje zpravidla umí jenom nějakou podmnožinu SQL podporovaného serverem, takže pokud potřebujete něco speciálnějšího (což při optimalizacích typicky potřebujete), skončíte stejně u slepování textů. Navíc složitější dotazy bude stejně vytvářet někdo, kdo aspoň trochu rozumí databázi, a napíše je v SQL – takže ve výsledku pak někdo musí SQL dotaz přepsat do tohohle speciálního jazyka, aby to pak nějaký nástroj slavnostně přepsal zpět do SQL. A všichni doufají, že z toho vznikne ten původní dotaz.
    23.4.2015 19:09 Matlák
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    SQL je beztypový jazyk

    uf. Asi jsi nikdy nedělal s postgresem?
    23.4.2015 19:22 Ivan
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Ok SQL ma typy ale.. Byly doby, kdy se predpokladalo, ze SQL bude takova jednodussi anglictina a ze to budou pouzivat vsichni. Proto standart pozaduje aby existovala implicitni konverze mezi stringem a datumem anebo mezi stringem a cislem. K cemu to pak vede to vime vsichni co SQL skutecne pouzivame.
    23.4.2015 22:05 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Můžete dát příklad, co přesně myslíte? Probíhá tam typová kontrola před spuštěním SQL skriptu?
    24.4.2015 04:39 Matlák
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Myslím třeba kontrolu shodnosti typů při psaní SQL dotazů. V postgresu nejde napsat WHERE sloupec = 5 když typ sloupce je varchar a naopak nejde napsat WHERE sloupec = 'ahoj' když sloupec je číselného typu. Vyhodí to výjimku, tedy pokud pomocí "::" hodnotu nepřetypujete (ovšem musí jít přetypovat že).
    24.4.2015 09:31 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    V postgresu nejde napsat WHERE sloupec = 5 když typ sloupce je varchar a naopak nejde napsat WHERE sloupec = 'ahoj' když sloupec je číselného typu. Vyhodí to výjimku
    Důležité je, kdy se to děje. Jestli se to děje až za běhu SQL skriptu, tak to není typový systém. Podle knihy Types and Programming Languages je typový systém:
    A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute.

    Another important element in the above definition is its emphasis on classification of terms—syntactic phrases—according to the properties of the values that they will compute when executed. A type system can be regarded as calculating a kind of static approximation to the run-time behaviors of the terms in a program.
    Typový systém tedy počítá statickou aproximaci chování programu. Např. Python žádný typový systém nemá, neboť před spuštěním programu se tam žádná aproximace jeho chování nepočítá.

    Nicméně máte pravdu v tom, že některé implementace SQL typovou kontrolu v určitých situacích dělají (např. při kompilaci uložených procedur), nevím však, zda je to součástí standardu?
    24.4.2015 11:01 OldFrog {Ondra Nemecek} | skóre: 26 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    No nevím, doteď jsem žil v domění že typovost a okamžik vazby jsou dvě rozdílné věci:
    • dynamic/late binding versus
    • strong/weak typing
    -- OldFrog
    24.4.2015 12:03 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Staticky se myslí "bez spuštění programu".
    No nevím, doteď jsem žil v domění že typovost a okamžik vazby jsou dvě rozdílné věci
    Ano, jsou to různé věci. O vazbě jsem nic nepsal.
    24.4.2015 12:09 OldFrog {Ondra Nemecek} | skóre: 26 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Dobře, takže máme statický a dynamický typový systém? V tom případě mi přijde, že typový systém ztotožňujete pouze se statickým. Nebo jsem to blbě pochopil?
    -- OldFrog
    24.4.2015 13:11 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    V tom případě mi přijde, že typový systém ztotožňujete pouze se statickým.
    Ano, přesně tak.
    24.4.2015 13:14 OldFrog {Ondra Nemecek} | skóre: 26 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    No a Smalltalk nebo ObjectiveC nemá tedy typový systém?
    -- OldFrog
    24.4.2015 13:37 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Smalltalk ne (alternativně lze říci, že má triviální typový systém s jedním typem – viz Dynamic Languages are Static Languages), Objective-C ano (neboť podporuje statictké typování).

    Můj postoj vysvětluje například Andreas Rossberg nebo Norman Ramsey v odpovědích na Does “untyped” also mean “dynamically typed” in the academic CS world?
    26.4.2015 14:43 Matlák
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Důležité je, kdy se to děje. Jestli se to děje až za běhu SQL skriptu, tak to není typový systém.

    Mno, definovat podle tohohle SQL jako beztypové mi připadá trochu přehnané. To můžu rovnou říct že ten jazyk nemá žádnou syntaxi, protože se správnost syntaxe ověřuje až při spuštění. Když se typy zjišťují před spuštěním operace, je to pořád rozlišování typů.

    "Beztypové" chování by pak mohlo být něco ala MySQL kde se typy implicitně převádějí (a maximálně vyhodí nějaké varování) a operace (zápis například) proběhne vždy bez ohledu na to, že typy nesouhlasí, a v nemálo případech se tak prostě na disky ukládají zmrzačené, popřípadě žádné informace.
    rADOn avatar 27.4.2015 10:35 rADOn | skóre: 44 | blog: bloK | Praha
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Když se typy zjišťují před spuštěním operace…
    Kdysi davno se SQL psalo primo do kodu a nejakej preprocesor z toho vybuildil rovnou kod na strachani se v datovych souborech. Tomu by se dalo rikat "typovy" pacz mohl strilet chyby uz pri kompilaci. Ano, mas pravdu, mysql se obcas chova kokotsky… ale pokud jedinej rozdil je ze ti misto jedny vyjimky vystreli jina, tak to neni silne typovy. To bys stejne mohl rikat ze je silne typovy python - interpret te taky posle do prdele kdyz mu podstrcis „1 + 'foo'“.
    "2^24 comments ought to be enough for anyone" -- CmdrTaco
    27.4.2015 17:26 Matlák
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    ale pokud jedinej rozdil je ze ti misto jedny vyjimky vystreli jina, tak to neni silne typovy.

    Pravda, ovšem MySQL výjimku nevyhodí, pouze varování (a to jen někdy) a prostě zapíše vždy, klidně i NULL. Výjimka by byla v takové chvíli požehnání, protože se dá odchytit a zobrazit chybová hláška, popřípadě zalogovat. Považuju "Fail early" za hodně důležité a typovost (ať už slabá či silná) tomu pomáhá.

    BTW Diskuse byla pouze o přídomku "beztypový", nikoliv "silně" či "slabě typový" jazyk. SQL se mi prostě jako "beztypové" nezdá. Toť vše.
    28.4.2015 12:03 DarkKnight | skóre: 24
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Vsechno je o tom, jestli dany databazovy server umite spravovat. http://dev.mysql.com/doc/refman/5.6/en/sql-mode.html
    17.4.2015 11:21 OldFrog {Ondra Nemecek} | skóre: 26 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Zkušenost nemám ani s jedním (v javě používám ActiveJDBC), nicméně bych podotkl, že orm nástroje často umožňují:
    • ovlivňovat která data se načtou hned a která líně (lazy and eager)
    • použít klasické sql (a s výsledkem pak už pracovat dle běžných zvyklostí orm nástroje)
    • sdružovat operace do dávek
    • použít cache
    Mají tyhle možnosti kolegové nastudované a vyzkoušené? Rychlost prostě zásadní měrou záleží na způsobu použití, velikosti dat, nastavení... a a bez bližšších údajů případně profilleru lze těžko říct, zda by bylo něco jiného rychlejší.

    Ještě ohledně Java 8, jinq, stream api - když pominu to, že tam lze snadno paralelizovat, tak hlavní přínos je IMHO v něčem jiném, než v tom, že by to mělo být nějak automaticky superychlé nebo to z programátora sejmulo nutnost nad rychlostí přemýšlet :-)
    -- OldFrog
    22.4.2015 21:59 Tomáš
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Zdravím

    Myslím, že vůbec nezáleží na tom jestli C# nebo Java. Klíč k výkonosti vidím spíše v pojetí ORM knihovny. Co očekávám od ORM knihovny? Dotazy vrací objekty, které podporují lazy loading a vrácené objekty (pokud mají unikátní klíč) jsou zapisovatelné . Prakticky vypadá lazy loading takto:

    Person.address
    se transparentně propíše jako
     select … from ADDRESS A where A.PERSON_ID = :PERSONID 
    a vytvoří se nová kolekce objektů adressa a vloží se do atributu Person.address. Zapisovatelnost objetů lze ukázat na příkladě:
    Person.name = "pepin";
    se mi propíše (na požádání nebo na konci transakce) na:
    update PERSONS P set NAME='pepin',… where P.ID =…

    Pokud má tyto požadavky ORM knihovna splňovat, tak jsou dvě cesty jak takových požadavků dosáhnout:

    1. Knihovna vrací proxy objekty. Příkladem jsou Hibernate/NHibernate, Entity Framework, … a 90% všech ostatních ORM.
    2. Knihovna vrací potomky nějakého generického ORM objektu. Nad ní jsou přes dědičnost definovány property (getter/setter) pro přístup k datům. Typickými zástupci této skupiny jsou Cayenne, Ujorm, Enterprise Objects Framework, Active JDBC. Žádný .NET ORM tohoto druhu neznám.

    Nyní se pokusím ukázat k jakým neblahým koncům vede přístup číslo 1. Metody (DAO) objektu (a ani jeho potomci) nemohou přímo přistupovat k vlastním datům(!). Kdyby metody udělaly, tak obejdou lazy loading hook implementovaný v proxy objektu. Veškerá business logika je pak vyšoupnuta do vyšších vrstev do kterých se data kopírují. Touto vlastností se zabije objektový přístup a cesta vede beznadějně k antipaternu anemického modelu. Programátoři si pro kopírování dat ulehčují práci a vznikají knihovny jako Automapper a jim podobné. Architektura je pak ukázkovým příkladem lasagne code a ke všemu se většinou nezadržitelně stává i kódem s Ravioli strukturou. Samotný kód business logiky pak tvoří pouze minoritní část, zbytek kódu je balast. Bezuzdné kopírování dat (deep copy) a vytváření objektů pak dává pěkně zabrat alokátoru paměti a garbage collectoru. Spotřeba paměti stoupá do závratných výšin a operations oddělení posiluje HW ;-)

    Další negativa proxy přístupu jsou jen kyselou špičkou na proxy ledovci:

    • typeof(vytvořený_DAO_objekt) vrací Proxy. Drobnost, která komplikuje zdánlivě jednoduché situace.
    • Obtížná práce s detached objekty. Množství výsledků google dotazu na LazyInitializationException asi mluví za vše.

    Abych nebyl úplně jednostranný, tak zkritizuji i druhou cestu.

    • Nefunguje code first přístup. Třídy DAO jsou generovány z modelovacího nástroje, které obvykle nepodporují verzování s možnostmi tfs/svn/git. Diff souborů modelovacího nástroje je většinou nepoužitelný a merge změn v generovaných DAO objektech se pak skoro nedá udělat. Řešení existují, ale zatím elegance code first nedosahují.
    • Protože nefunguje code first, tak nejdou dobře dělat inkrementální změny v databázi na bázi kódu. popis knihovny C# a knihoven Java.

    Žádná z výtek k cestě 2, ale nemá vliv na výkonnost a udržovatelnost aplikace. To že se nedá jít cestou code first a jde se cestou model first, já osobně považuji spíše za plus, protože se snáze odchytí pokřivené datové modely. Například teď jsem narazil na jeden projekt s přístupem code first, kde místo vazeb 1:N vytvářeli vazby M:N (s vazební tabulkou), protože jejich (homemade) ORM nepodporovalo vazby 1:N. Přirozeně taková chyba má velmi negativní výkonostní dopad a absence podstatných integritních kontrol v databázi navíc vytváří prostor pro datové chyby, které následně i vznikají. Osobně považuji důslednou kontrolu datového modelu jako velmi účiný a jednoduchý způsob jak zabránit zásadním chybám při analýze a následném vývoji SW. Taková kontrola se u přístupu database first mnohem lépe dělá.

    Ale zpět k dotazu C# vs. Java. To jestli se bude psát dotaz jen s pomocí konstrukcí Java 1.4 v Cayenne ( rok 2005 )

      SQLTemplate q = new SQLTemplate(Person.class, "select * from PERSON where name ='pepin'");
      // SelectQuery q = new SelectQuery(Person.class, ExpressionFactory.Equal(Person.nameProperty,"pepin")); // anti sql injection version
      List p = ctx.peformQuery(q);
    

    nebo LINQ ( rok 2007 )

      var query = from p in person
                where (p.name = "pepin")
                select p;
    
    nebo ve stylu Java 8 ( rok 2014 )
      Person.stream().filter(s-> s.name="pepin");
    

    považuji spíše za kosmetické než revoluční změny vedoucí ke zvýšení výkonu. Klíče k výkonné a udržovatelné aplikaci leží totiž úplně jinde.

    Mimochodem, asi jste zaregistrovali, že příklad z Cayenne je nejstarší - circa z roku 2005. Příklad pro Enterprise Objects Framework by byl ještě o 10 let starší, tedy cca z roku 1996(!).

    22.4.2015 23:02 OldFrog {Ondra Nemecek} | skóre: 26 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    1+ hezky rozebráno, něco jsem se dozvěděl :-)
    -- OldFrog
    23.4.2015 10:26 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Veškerá business logika je pak vyšoupnuta do vyšších vrstev do kterých se data kopírují. Touto vlastností se zabije objektový přístup a cesta vede beznadějně k antipaternu anemického modelu.
    Anemický model není antipattern – je velmi přirozené jednotlivé věci oddělit a zvýšit znovupoužitelnost kódu. Naopak splácat vše do jedné třídy je antipattern.
    24.4.2015 05:31 Matlák
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Tohle je otázka - mně jako vývojáři na jednu stranu vyhovuje, když mám vrstvy oddělené a můžu třeba i jednoduše vyměnit databázový framework (s IoC kontejnery je to velmi snadné), navíc se hodí mít pro cachování jinou sadu objektů než pro práci s DB, na druhou stranu to co napsal Tomáš o tunách "balastkódu" a hromadou mapování (třeba takový Dozer - už ten název napovídá, že jde o buldozer na shrabování ohromných hromad objektů :-)) je pravda.

    Lehké frameworky typu Cayenne (třeba český Ujorm) jsou v tomhle lepší, nepotřebují tolik objektů - ale na druhou stranu je pak návrh aplikace s nimi těsně svázán, přechod na jiný framework je velmi obtížný, je tu problém s cachováním a serializací a pokud chcete mít v aplikaci více API pro různé účely, nakonec se hlubokému kopírování a mapování stejně nevyhnete.
    rADOn avatar 24.4.2015 12:58 rADOn | skóre: 44 | blog: bloK | Praha
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Hezky rozepsany. Me z toho plyne ze je to vzdycky neco za neco, a pro cloveka ktery si umi napsat dotaz je orm celkem k nicemu.
    "2^24 comments ought to be enough for anyone" -- CmdrTaco
    24.4.2015 13:12 OldFrog {Ondra Nemecek} | skóre: 26 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Spíš naopak :-) Když umím sql, nemám problém s orm (které mi může ušetřit dost práce).
    -- OldFrog
    rADOn avatar 24.4.2015 14:28 rADOn | skóre: 44 | blog: bloK | Praha
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    No ja v zadnym z tech prikladu co jsi psal zase tolik usetreny prace nevidim. Spis praci zametenou pod koberec. Nemuset priblble opisovat fetchnuti hodnot do atributu objektu je bezva, imo cokoliv slozitejsiho ma stejnej pocet problemu jako vyhod. Treba liny dotahovani je pro me ve vetsine pripadu nevyhoda, pacz to nafukuje transakce a muze to drazdit deadlocky, takze nakonec klicovy casti stejne budu psat rucne (s execution planem v ruce). ORM mi muze pomoct nabouchat prototyp, ale pokud mi bude stat v ceste pri ladeni vykonu tak to zase tolik prace neusetri, jen ji to presune nekam kde to neni hned videt. BTW proto taky vsechny ORM co jsem videl se v prvni rade kasaji jak umi krasne jednoduse nabouchat administracni rozhrani – protoze to je uloha kde na efektivite zase tolik nezalezi.

    Disclaimer: jsem zaujatej pacz od javy jsem utekl, v Cecku jen veci kde na vykonu hodne zalezi a v pythonu jsou tyhle debaty vicemene smesny…
    "2^24 comments ought to be enough for anyone" -- CmdrTaco
    24.4.2015 14:34 OldFrog {Ondra Nemecek} | skóre: 26 | blog: Žabákův notes | Praha
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Souhlasím s tím, že záleží případ od případu - pročež jsem ostatně řekl, že ORM práci ušetřit „může“.
    -- OldFrog
    Max avatar 27.4.2015 10:48 Max | skóre: 65 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Java 8 - Data Access vs. Entity Framework
    Pánové, jen bych chtěl poděkovat za podnětnou diskusi, která mně torchu zasvětila do problematiky a objasnila několik věcí.
    díky
    Zdar Max
    Měl jsem sen ... :(

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.