Hlavní navigace

Názor k článku Novinky v Javě aneb Tygří spáry od zephir - Já nový flame zakládat nehodlám - na druhý...

  • Článek je starý, nové názory již nelze přidávat.
  • 10. 11. 2003 16:41

    zephir (neregistrovaný)

    Já nový flame zakládat nehodlám - na druhý straně vaše obavy z mý odpovědi tak trochu chápu...;-) Především věta že .NET OLEDB ma zatim do Java JDBC daleko je tak trochu nesmysl, protože něco jako ".NET OLEDB" v .NETu neexistuje. Existuje tu jen OLEDB provider pro ODBC datový zdroje, ale pro MS SQL nebo Oracle existuje samostatná datová vrstva. Ale ta hlavně nepředstavuje základ databázových technologií .NETu, to je jenom datová pajpa - "trubka na data".

    Základem DB technologií je vrstva ADO.NET což je v kostce engine pro in-memory replikační XML databáze. Myslím, že schopnost JDBC3 končí někde kdesi u odpojených datasetů (CachedRowSet) a sortování a filtraci rowsetu - ale už nepodporuje fíčury klasického ADO (datashaping, hiearchický, vícenásobný a relační rowsety a recordy, distribuovaný datový zdroje a persistenci a indexaci datasetu - a to jsme stále u klasické, sedum let staré COM technologie - nikoliv .NETu. Ten k tomu navíc přidává referenční integritu a replikační engine. Pomocí ADO.NET lze relativně jednoduše aplikaci vybavit off-line databázovým engine, který cachuje změny v relačních tabulkách (dataset zde není jednoduchý nebo několikanásobný rowset - ale kompletní relační databáze s udržování konzistence, co se týče DRI a datových typů) a při replikaci/synchronizaci je propíše do podkladové databáze.

    Pokud ani teď netušíte, co ADO.NET umí anžto ho usilovně srovnáváte s JDBC (a co víc, snažíte se přisoudit tento omyl mě...) - pokusím se objasnit základní myšlenku ADO.NET na příkladu: Mám smart klienta napsaného v .NETu, který si po spuštění v režimu on-line natáhne kompletní data ze všech tabulek týkající se daného konkrétního uživatele včetně constraintů a relací do datové struktury, kterou lze snadno (jediným příkazem) serializovat na disk a vytvořit tak pro klienta jeho vlastní kopii databáze. Off-line uživatel si v ní data šudlá, mění maže a upravuje tak dlouho, než má možnost/potřebu práce v režimu on-line - ADO.NET s datovým vzorkem přitom stále nakládá tak, jako by byl pořád připojený on-line. A nakonec se klient připojí se na server buď přímo, nebo přes middle-tier vrstvu webových služeb a propíše jediným příkazem všechny změny do databáze zpět. V zásadě jde o replikaci dat a v trochu odlehčené a redukované podobě to funguje i po dobu web session na web serveru, kdy třeba uživatel kliká po e-biz serveru semo tamo a modifikuje nákupní košík (zde se ovšem in-memory databáze udržuje pouze v paměti). ADO.NET engine se přitom stará o všechny otázky s tím spojené - třeba replikační identifikátory, správné pořadí update relačně svázaných tabulek při jejich replikaci, optimalizaci - indexaci a datové manipulace, dotazování z DataSetu atd.) - čili zdaleka zde nejde vůbec o nějakou OLEDB nebo SQLDB vrstvu, což je pouze kurzorový engine na nejnižší vrstvě téhle technologie.

    A to celé je pěkně prosím součást základní funkcionality .NETu, kterou si stáhnete free z MSDN, je prefektně zdokumentovaná (pokud nevěříte, porovnejte si v Google počet výsledků na "+sort +filter +Rowset" (430 výsledků) a "+sort +filter +DataSet" - 42.000 výsledků) a je pěkně integrovaná do Visual Studia.NET (databinding, design-time containery, atd.) a funguje to pěkně i ve standard verzi VS.NET za 4.000,- Kč (v profi verzi VS.NET platíte za generátory sestav a enterprise rozšíření, ale nikoliv za popsané features).

    Jinými slovy, technologie jsou to nesrovnatelné - protože co se DB technologií týče, zde MS staví na více než desetiletých zkušenostech s vývojem ODBC, RDO a OLEDB/ADO.