.NET – Anketa 1.část

Diskuze čtenářů k článku

David Petrla  |  22. 02. 2002 15:50

Pane autore seriálu, dovolte otázku:

Vyjde to pak knižně?

Doporučuji!!!

Souhlasím  |  Nesouhlasím  |  Odpovědět
Winco  |  22. 02. 2002 13:58

Je to mile, ale dalo by sa to dost skratit.

Souhlasím  |  Nesouhlasím  |  Odpovědět
Gwamb  |  22. 02. 2002 11:28

Rs(0) bych zas tak vehementne nezatracoval. Nezapomente, ze Collection je objekt, ktery index pouziva uplne jinak nez KeyName. A skutecne pouziti indexu je rychlejsi a ne urcite o 0,1%. Zkuste si udelat zatezovi test vybirani pvku z velke collection pomoc indexu ci pomoci keyname.

Pouziti KeyName ma i dalsi neduhy. Pokud dojde z nejakeho duvodu ke zmene jmena sloupecku, musite tez rucne menit cely zdrojovy kod, aby tato zmena byla reflektovana.

Argument, ze kod ma byt citelny za kazdou cenu neni taky tak uplne pravda. Dulezite je aby byla v celem programu pouzita stejne uprava kodu, ale to co je nejdulezitejsi je programatorska dokumentace a poznamky v kodu. Je sice hezke videt, ze se pouzije TopicName = rs("Name"), ale kdyz u toho neni napsano co ten radek vlastne ma znamenat, tak je mi jedno, ze tam je pouzito KeyName. Pokud v kodu najdu radek TopicName = rs(0) a u toho poznamku o co se jedna, tak to uplne staci :)

Nehlede na to, ze nasledujici kod pro kopirovani dat z kolekce do pole je strasne elegantni:
long j = collection.Count;
for (long i=0; i

Nehlede na to, ze se ve svete .NET setkate s kolekcemi, kde se na nektere prvky jinak nez prez index nedostane. Napriklad. pokud provadite update dat v ASP.NET strankach v DataGridu, tak se zmenene udaje dostanete za pouziti e.Item.Cells[2].Controls[0], tady moc nelze pouzit jmena, protoze prvky kolekce Controls jsou dynamicky generovany mimo Vasi aplikaci. Jedina na co se lze spolehnout je pouzit indexu.

Zaverem. Indexovani kolekci bych v zadnem pripade nezatracoval :)

Souhlasím  |  Nesouhlasím  |  Odpovědět
Petr Paleta  |  22. 02. 2002 12:12

Ale já nemluvím o obecném výběru z kolekce podle indexu, ale o výběru pole recordsetu podle indexu nebo podle jména pole. A v tom případě s vámi absolutně nemohu souhlasit.

Pokud jde o testy podobných případů, dělal jsem jich hodně (samozřejmě ne na tento případ), a mám dost přesný odhad, kolik trvá jaká akce s databází a v paměti. A věřte mi, tím výběrem z recordsetu neušetříte nic, co by stálo za řeč vzhledem k délce databázového dotazu. Ta collection bude poměrně malá, protože nikdy netaháte na klienta příliš mnoho polí. 

Pokud dojde z nejakeho duvodu ke zmene jmena sloupecku, musite tez rucne menit cely zdrojovy kod

To ano. Ale:

  • většinou dojde ke změně konkrétního databázového dotazu daleko spíše než ke změně jména sloupce v databázi

  • lepší řešení je konstanta cv_Name místo "Name". Ještě lepší řešení, které ve firmě používáme, je samozřejmě oddělení databázových dotazů pryč z prezentačního kódu, pak se pracuje stylem:
    Topic.Load()
    if (Topic.Name = .....)
    Objekt pak v sobě obsahuje funkce pro vlastní načtení, takže se změna v databázi opravuje pouze na jednom místě, nehledě na to, že může být vhodnější načítat objekt procedurou spíše než SQL dotazem. Ale to je samozřejmě nad rámec článku.

  • Naprosto nesouhlasím, pokud jde o čitelnost. Program MUSÍ být samodokumentovatelný, aby ten, kdo ho čte, ho nemusel luštit. Dokumentace pak může být méně podrobná a popisovat, CO program dělá a ne jak. Když někdo čte kód, zpravidla nekouká levým okem do dokumentace a pravým do kódu. A každý kód v reálné aplikaci je nejméně desetkrát čten, často pokaždé něčím jiným, a při jeho psaní je NUTNÉ počítat i s tím, že bude program čten.

    U Rs("Name") se také nevyhnete komentáři, co se z té databáze tahá a proč. Ale nemusíte už komentovat každý řádek, zatímco Rs(číslo) dokumentováno být musí. Jak známo, nejlepší jen kód, který nemusíte napsat, protože v něm nemohou být chyby a nikdo ho nemusí číst. A to se týká i komentářů. Je lepší psát kód tak, aby NEVYŽADOVAL tolik komentářů, to je přece jasné.

    Pokud jde o obecné kopírování kolekce nebo další případy použití indexů, které uvádite, nemám vůbec nic proti.

     

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    David Petrla  |  22. 02. 2002 15:48

    Stoprocentně souhlasím s tím, že program musí být samodokumentovatelný.

    Prostě musí se v něm dát číst jako v knize a většina věcí musí být hned jasná. Rozumí se zkušenému programátoru, který ale nezná daný program.

    Komentáře nic nezachrání. To je běžný - ale veliký - omyl.

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    Tomáš Tichý  |  22. 02. 2002 18:39

    Zdravím, zkoušeli jste například e.Item.FindCotrol ?

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwebuicontrolclassfindcontroltopic.asp

    nevím sice, jak vypadá váš kód, takže nevím, zda se to dá použít ... napište jestli pomohlo.

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    Jiri Hanzl  |  22. 02. 2002 11:17

    Snažil bych se omezovat klientské skriptování používáním input/image nebo submit.

    I ten kalendář z Web forms na klientu vystavuje in-line skriptíky. 

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    Gwamb  |  22. 02. 2002 11:30

    Ty in-line skripty zalezi na typu pouziteho prohlizece. Pokud budete mit prohlizec, ktere nepodporuje client-side skripty, tak je vse provadeno prez server.

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    Petr Paleta  |  22. 02. 2002 10:04

    Nezlobte se na mě, ale konstrukce TopicName = CStr(r(0)) je zcela principiálně chybně a neměla by se vyskytovat ve výukovém materiálu.

    Ne, že by nefungovala, dokonce možná je skutečně o pár nanosekund rychlejší než použití jména pole. Ale pane Tichý, víte kolik trvá i nejmenší databázový dotaz, zvláště když máte mezi web serverem a databázovým serverem vnitřní firewall? Jsou to řádově milisekundy. Touto konstrukcí tak ušetříte řádově 0,1% času zpracování dotazu. Čistě pro srovnání, vhodnou volbou clusterových indexů, o které nemluvíte (nevýtýkám to, nepatří to do problematiky článku, a možná je v tomto případě SQL server dokonce trefí sám), ušetříte tak 99% času dotazu (až budou tabulky pořádně naplněny). A stále bude prostor aplikaci dále optimalizovat uchováním počítaných agregátů v nadřízené tabulce! 

    Chyba je v tom, že tato konstrukce není stabilní a samodokumentovatelná. Stabilní znamená, že jakmile někdo změní o pár řádek výše SQL výraz, tak mu tento kód nebude fungovat, nebo dokonce bude zobrazovat data ze špatného pole.

    Není samodokumentovatelná, protože když někdo čte kód, musí někde složitě hledat, co Rs(0) znamená, a nebo musí k tomu číst komentář, který někdo musel napsat. Rs("Name") je jasné a žádný komentář nepotřebuje.

    Je zcela nepochopitelné, že většina programátorů se snaží honit zlomky milisekund v podobných případech, za cenu snížení srozumitelnosti kódu. Pokud jde o větší projekt na kterém pracuje více lidí, vedou podobné praktiky k mnoha chybám, jejichž odstranění je strašně drahé. Bohužel, máme s tím ve firmě vlastní zkušenosti, nehledě na tisíce knih, které se tím zabývají. Daleko více se vyplatí programovat defenzivně a srozumitelně za cenu minimální ztráty výkonu v podobných případech a ušetřený čas pak věnovat na optimalizaci algoritmů nebo databáze (hraní si s indexy apod.), nebo za ušetřené peníze na vývoji koupit o 10 procent výkonnější server. Vyjde to levněji, nehledě na ty nervy při ladění.

    Nejde samozřejmě jenom o Rs(0), ale o způsob programování celkově. Je třeba si uvědomit, že programový kód dnes většinou už není seznam instrukcí pro počítač, ale daleko více srozumitelný popis funkcí aplikace, kterému musí kromě ostatních členů týmu rozumět také ten nepříliš inteligentní, ale velmi akurátní počítač.

    Proto upřimně doporučuji všem programátorům, na Rs(0) zapomeňte, jako by to neexistovalo. A prosím všechny lektory, aby ho ve výukových příkladech neuváděli.

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    martin  |  22. 02. 2002 14:25

    Obcas konstrukci typu Rs(0) take pouzivam, ale jinak zlata slova a absolutni souhlas!

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    Ufak  |  22. 02. 2002 14:33

    Souhlas, uz se mi to stalo, ze jsem musel dohledavat, nebo se zmenil seznam poli. Proste sranda.
    Zdrojovy kod je take dokumentace!

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    David Petrla  |  22. 02. 2002 15:45

    Pěkné, Petře. Však ti také trvalo, než jsi mne o tom přesvědčil. Nyní ti tedy veřejně dávám plně za pravdu.

    Akorát by ještě bylo dobré odstranit doporučení používat Rs(0) z materiálů Microsoftu. Doporučují to na mnoha místech.

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    Tomáš Tichý  |  22. 02. 2002 18:34

    Par poznámek k příspěvku. V daném případě musím souhlasit, že co získáme rychlostí určitě mnohokrát ztratíme na samodokumentovatelnosti kódu. To je fakt a chyba, které se dalo vyvarovat. Příkaz bude nestabilní vždy, protože změnou SQL dotazu můžeme například daný sloupec vynechat, nebo se může změnit tabulka, atd...

    ... vhodnou volbou clusterových indexů, o které nemluvíte ...

    Ano nemluvím a ani mluvit nebudu, jako DB používáme v příkladech Access. Pro nasazaní v profesionální sféře bychom tu komponentu stavěli trošičku déle než 1 díl seriálu.

    Obecně ale nemůžu souhlasit s posledním řádkem. Vyhledávání podle indexu je mnohem rychlejší (řádově 2.5-4 krát při běžné aplikaci, nezkoušel jsem worst-case analýzu). Takže nemůžu než dodat:  r(0) používat můžete, ale vždy zhodnoťte, zda vám to sotjí za to.

    Přeji hezký den

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    Petr Paleta  |  22. 02. 2002 19:29

    Vyhledávání podle indexu je mnohem rychlejší (řádově 2.5-4 krát při běžné aplikaci, nezkoušel jsem worst-case analýzu). ...  r(0) používat můžete, ale vždy zhodnoťte, zda vám to sotjí za to.

    Omlouvám se, že se musím ozvat, ale tohle je obrovský omyl ve způsobu uvažování. I kdyby bylo vyhledávání podle klíče 1000x rychlejší, neušetří z celkové doby trvání SQL dotazu a jeho zpracování více než 0,1 procenta, pokud půjde o reálnou aplikaci, když bude databáze jinde než na webovém serveru. A za to nečitelnost kódu prostě nestojí!

    BTW: Pokud používáte Access, který nemá clusterové indexy, lze stonásobně zvýšit rychlost udržováním agregovaných záznamů, které se teď počítají v každém dotazu, v master tabulce. Udělejte to, a nebudete se muset starat o nanosekundy.

    Tady samozřejmě nejde jenom o nějaké Rs(0), ale o celý styl programátorského myšlení. Když budou podobné hrůzy uvedeny v takovýchto jinak výborných článcích, začínající programátoři získají dojem, že je správné přemýšlet o tom, jak zoptimalizovat každou strojovou instrukci, místo aby pochopili, že programování je (většinou) o něčem úplně jiném a v běžných aplikacích nemá absolutně žádný smysl nad podobnými nanosekundami uvažovat, zvláště když se za ně platí kvalitou kódu.

    A věřte mi, že čeští programátoři jsou dnes většinou docela dobře vzdělaní pokud jde o ryze technické věci, ale totálně mimo pokud jde o softwarové inženýrství, tedy hlavně o schopnost vytvořit reálnou aplikaci v týmu, který se nevejde do jedné místnosti. Mám o tom docela dobrou statistiku, protože mám na starosti výběr uchazečů na programátorské pozice. A skutečně, věřte mi, z tohoto pohledu je to naprostá hrůza. Proto Vás prosím, i když je Váš seriál o něčem jiném, snažte se, aby byl demonstrovaný kód kvalitní i z tohoto pohledu.

    Jinak se těším na další pokračování seriálu, jako úvod do .NET je skutečně velmi dobrý.

     

     

     

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    Tomáš Tichý  |  22. 02. 2002 19:57

    O koze a voze... v mém posledním příspěvku jsem napsal, že v daném případě je lepší použít jméno místo indexu. Čekání na SQL dotaz skutečně znehodnotí jakoukoliv další optimalizaci.

    Poslední věta se týkala kolekcí obecně, kde indexový přístup může získat navrch právě kvůli efektivitě kódu i s přihlédnutím na to, že nebude tolik předhledný. Vždy je jenom potřeba zvážit výhody a nevýhody.

    Abych ale řekl taky něco z vlastní zkušenosti. Právě proto, že dolování dat z SQL db je to, co brzdí celý program,  můžou se použít v ASP.NET techniky pro cachování získaných dat. Toto je důležité hlavně při veliké komplexnosti stránky/dotazů do DB. Pokud je stránka pomalá i potom, přichází na řadu optimalizace samotného kódu ve VB, kde už můžou být věci které jsou několik krát rychlejší použitelné. Opět - nechci tím  říct, že máme dělat prasácký kód, který sice bude rychlý, ale nikdo kromě autora ho nepochopí.

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    J. Prikryl  |  22. 02. 2002 08:58

    Diky, jen vice.

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    PetrM  |  22. 02. 2002 07:59

    Uvedeny priklad ma jeste jedno slabe misto pri ochrane proti vicenasobnemu hlasovani. Je jim tlacitko back...

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    Tomáš Tichý  |  22. 02. 2002 08:22

    To není úplně pravda. Je sice pravda, že po stlačení tlačítka BACK se stránka přesune zpátky - tz. je možné znovu kliknou na otázky, ovšem systém si už ohlídá, jestli daný uživatel hlasoval - se hlas nepřičte. Proti cachování na straně browseru nemáme jako vývojáři žádné jiné "prostředky boje". Chtěl jsem se vyhnout nastavení Response.Expires = 0, protože v příštím dílu si uděláme ze dnešního zdrojáku samostatnou komponentu. A u komponenty by nebylo vhodné nastavovat tuto vlastnost, protože ta náleží celé stránce, ne jenom dané komponentě.

    Přeji hezký den

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    Ufak  |  22. 02. 2002 06:51

    Povazuji to za 4. dil

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    Tomáš Tichý  |  22. 02. 2002 08:23

    Ano, je to v podstatě 4. díl, akorát jsem nechtěl psát .NET - Anketa 1 - díl 4.

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    Antal Stasek  |  22. 02. 2002 03:34

     Mam chut na tatranky Opavia

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    Antal Stasek  |  22. 02. 2002 03:30

    Mislim, ze Tomas Tichy je opravdovy odbornik

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    keywitch  |  22. 02. 2002 02:03

    no, nevim nevim, ja bych rek ze anketa ma jednu otazku a nekoli odpovedi a ne nekolik otazek, jak je v tomto clanku

    Souhlasím  |  Nesouhlasím  |  Odpovědět
    Zasílat názory e-mailem: Zasílat názory Můj názor