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í
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
včera 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 1
včera 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 5
včera 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 0
včera 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
včera 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 0
včera 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
1.12. 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
1.12. 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 0
1.12. 15:16 | Komunita

Na GOG.com začal zimní výprodej. Řada zlevněných her běží oficiálně také na Linuxu. Hru Neverwinter Nights Diamond lze dva dny získat zdarma. Hra dle stránek GOG.com na Linuxu neběží. Pomocí návodu ji lze ale rozběhnout také na Linuxu [Gaming On Linux].

Ladislav Hagara | Komentářů: 1
1.12. 13:14 | Bezpečnostní upozornění

Byla vydána verze 2.7.1 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Řešeno je několik bezpečnostních problémů. Aktualizován byl především Tor Browser na verzi 6.0.7. Tor Browser je postaven na Firefoxu ESR (Extended Support Release) a právě ve Firefoxu byla nalezena a opravena vážná bezpečnostní chyba MFSA 2016-92 (CVE-2016-9079, Firefox SVG Animation

… více »
Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 759 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Java 8 - Data Access vs. Entity Framework

Max avatar 16.4.2015 09:15 Max | skóre: 64 | blog: Max_Devaine
Java 8 - Data Access vs. Entity Framework
Přečteno: 846×
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: 25 | 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: 25 | 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: 25 | 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: 25 | 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: 25 | 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: 25 | 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: 25 | 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: 64 | 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.