"G." <na@na.lt> wrote in message news:hsulrq$9qb$1@trimpas.omnitel.net... > Kategoriška nuomonė retai būna teisinga :) > > Nesutinku dėl SQLCommand ir parametrų - jie leidžia išvengti elementarių > klaidų tokių kaip SQL injection. Blin tai imi ir tikrini, ka tingisi? pas mane spec libas yra visam tam kad jokiu injectionu nieks neindes niekad... jokios cia problemos nematau isskyrus 1 problema, tingejima pasirasyt tam klase ar metoda... >Maišyti kintamųjų tipus (integerius paduoti > kaip stringus, nvarchar'us lyginti su varchar'ais ir t.t.) SQL serveriui > irgi nėra pati geriausia įdėja, nes jis turės užsiimti visokiom konversijom, > negalės naudoti indeksų ir panašiai. Taip pat, parametrizuoti queriai yra > vykdomi kitaip nei neparametrizuoti. O tu manai jis juos gauna ne kaip teksta ant galo ? plius MSSQL konversiju pats darai kruvom, nes jos daznai neisvengiamos MSSQL atveju, taip kad irgi nereikia lialia, palyginus kiek ten prarasi performance tai pats posto autorius rase kad paprastas string veikia zymiai greiciau nei kad su command parametrais, ir greiciai skiriasi stipriai, ta prasme tavo tipo geras variantas zymiai letesnis, pasiskaityk 1 posta... taip kad cia irgi briedas.. > > Tam, kad naudoti interfeisus, vieningai atidarinėti connectionus, vykdyti ir > loginti sql komandas, visiškai nebūtina atsisakyti ADO.NET bibliotekų - > šitie dalykai vienas kitam neprieštarauja. Gali ant ADO.NET ir DBCommand > viršaus turėti savo abstraktesnius interfeisus, ar naudoti enteprise library > data access bloką, kokį nors ORM (nhybernate, linq to sql ir t.t.). Visada > geriau naudoti kažką egzistuojančio ir populiaraus nei išradinėti savo > dviračius, nes: > a) kitų rašytas bibliotekas testuoja ir bugus taiso kiti > b) naujai pasamdytas programeris gali mokėti ADO.NET, nhybernate, linq, bet > tikrai nemokės naudoti jūsų inhouse framework'o. Eilini kart lietuviskas tingejimas ir nepasitikejimas savo jegom, na kiekvienam aisku savo, man nesunku tai daryti ir darau, man tas gal net idomu ir nesiskundziu veikimu, tiesiog visada buvau labiau link System Core del to man tai norma, tai darau jau 10+ metu, tiek kiek teke su VB seniau, kiek veliau su C++, VB.net ar C# visur teke rasyt core libus ir praktiskai atmintinai zinau, versiju ju buve kruvos, siaip man tai idomus uzsiemimas paprasciausia... > > Žinoma viską reikia pasverti ir daryti su protu, nešaudyti žvirbllių > patrankomis, bet teigti, kad primityvus stringų dėliojimas yra visais > atvejais geriau už ADO.NET yra ... lame! :) Prie ko cia ADO.NET, as ir pats ji daug naudoju, tik ne parametrus, jei tau komandos parametrai tai viskas kas yra ado.net tai tu ziuri i viska labai siaurai.... as ADO.NET naudoju, nenaudoju tik komandu parametru, pripazystu kad jos gerai rasant universalia db access core, kada dirbama su skirtingom DBVS... O del visko laikymo kaip stringu tai tavo reikalas, gali knistis ir daryt kitus tipus... jei tau nuo to bus geriau ;) man taip yra greiciau programint ir nuo to bet kuriuo atveju ne ram ne performance daug neprarasi, bent tiek kad nuo to tau priklausytu tavo honoraras.. o gal tu kokiam microsofte dirbi ?