Kilépett a Java fejlesztését irányító testületből az Apache
2010-12-13T21:29:19+01:00
2010-12-23T21:25:30+01:00
2022-07-19T04:28:14+02:00
  • Az alkalmazásszerver azt jelenti, hogy a BL-ed ott csücsül az adatbázisszervered felett, és kommunikál a kliensekkel. Azaz a kliens nem select parancsokat küldözget a hálón, hanem üzleti objektumok vándorolnak ide-oda. Régebben CORBA-val csinált ilyesmit az ember, manapság a WCF-et használom erre.
    De ezt a BL-t nem kell RDBMS-enként megírni, és debuggolni sem túl nagy feladat. És ha nem csak desktop UI kell hanem mondjuk SMS-en keresztül akarod vezérelni a rendszert (például) akkor is csak azt a klienst kell megírni ami csatlakozik a fenti szerverhez és küldözgeti / fogadja az objektumokat.
    Mutasd a teljes hozzászólást!
  • Ha több ezer géped van az már alkalmazásszerver.

    Egyrészt miért? Ez a fizika törvényeiből következik, vagy mi? Másrészt nem arról volt szó, hogy ezer párhuzamos kliensed van szerveroldalon, hanem arról, hogy ezer csomópontod a hálózaton, amelyek mindegyike potenciálisan hozzáférhet az adatbázishoz. Ilyen körülmények között a biztonsági, adathozzáférési és adatmanipulációs szabályok betartását a kliensre bízni az adatbázisszerver helyett dőreség és dilettantizmus.

    Arról ne is beszéljünk, hogy milyen már alkalmazásszerverrel jönni akkor, amikor azok a legkomolyabb érvek a tárolt eljárások használatával szemben, hogy "de hát azokat akkor külön meg kell írni", meg hogy "nehézkes a karbantartása, és nem lehet beledebugolni". Miért, az alkalmazásszervert nem kell külön megírni, meg abba csak úgy bele lehet debugolni???

    És ha sokszor kell település távolságot számolnod akkor jobban jársz egy mindig a RAM-ban tartott csomópont-él objektumhalmazzal mint ha a tárolt eljárás szedegetné elő minden híváskor az adatbázisból.

    Egy szemléltető példát mondtam - nem a koordináták, meg a konkrét feladat voltak a lényegesek az egészben, hanem az, hogy ha olyan jellemző alapján akarsz az adatok között szűrni vagy azokon műveletet végezni, amihez nem biztosít elemi függvényt ill. operátort az adatbázisszerver, akkor ha kliensoldali query-kre korlátozod magad és kizárod a tárolt eljárások használatát, akkor sajna gyakorlatilag az összes adatot át kell passzíroznod a kliensoldalra a szűrés vagy a művelet elvégzéséhez, ami marhára drága tud lenni.

    Az meg, hogy az előre felolvasás vagy a tárolt eljárás -e az effektívebb, sok minden függvénye, még akkor is ha a konkrét példáról (GPS pontok közötti távolság számítása ill. ez alapján minimumkeresés) van szó. Pl. ha minderre a funkcionalitára egy weboldalak mögötti PHP szkriptből van szükséged (amiben az adatbáziskapcsolat, az adattér és akár még maga a processz is csak egy-egy oldalletöltés erejéig él), akkor hajadra kenheted az előre felolvasást, mert nem lesz gyorsabb, sőt, sokkal lassabb lesz, mint a tárolt eljárásos megoldás.
    Mutasd a teljes hozzászólást!
  • Igen, a prepared statement-ek használhatósága korlátozott, de a mindig akkor sem állja meg a helyét.

    Bocs, de ez csak öncélú kötözködés részedről. A "mindig" alól én magam is írtam kivételt még azon a mondaton belül - tehát teljesen egyértelmű volt, hogy az nem a szó legszigorúbban vett, hanem a hétköznapi értelmében értendő (ami nem azt jelenti, hogy "az esetek 100.00%-ban, kivétel nélkül, örökérvényűen az idők kezdetétől fogva a végéig", hanem azt, hogy "jellemzően", "nagyon sokszor", "rendszeresen"). De ami igazán hiteltelenné teszi az egész érvelésed az az, ha megnézzük, hogy te magad is simán használod úton-útfélen (1, 2, 3) a "mindig"-et olyan helyzetek leírására, amelyekben teljesen egyértelmű, hogy nem a szó "az esetek 100%-ban, kivétel nélkül" jelentését alkalmazod. Ezek után nekiállni lovagolni ezen.... Háááát....

    "A harmadik dolog, hogy a C#-ból csak egyirányban tudsz kommunikálni az adatbázisszerverrel, az közvetlenül nem tud a te üzleti logikádba visszahívni vagy téged az adatbázisban bekövetkezett specifikus változásokról értesíteni."
    Ez db függő, ahogy írtam is rá példákat. Tehát a csak megint nem állja meg a helyét.

    Nem, te nem arra írtál példákat, hogy az adatbázis szól vissza ha változott, hanem arra, hogy az adatbázisszerver lehetőséget ad az alkalmazás (!) - adott esetben a C# program - egy másik példányának, hogy értesítést küldjön az adatbázisszerveren keresztül, ami ilyenkor kvázi csak egy újrahasznosított IPC-csatornaként működik. Ettől még az adatbázis maga - ha nincsenek benne tárolt eljárások, amik vagy triggerekhez vannak kapcsolva, vagy eleve az egyetlen adatmanipulációs felületet és módot képezik kifelé - bizony egy fél értesítést nem fog maga generálni, ami azt jelenti, hogy a kommunikáció egyirányú lesz vele, és nem fog visszahívni az üzleti logikádba, és nem fog értesíteni téged arról, hogy mondjuk XY tábla megváltozott.

    Arról már ne is beszéljünk, hogy ezeket az értesítéseket is kvázi pollozással kell figyelni, ill. nem lehet blokkolni rajtuk a hívás/küldés helyén, tehát megint csak nem lesz igaz, hogy segítségükkel vissza lehetne hívni az alkalmazási logikába úgy, ahogy a tárolt eljárások egymás között megtehetnék az adatbázisban, ha azokba kódolod bele az üzleti logika releváns részét.

    Pont úgy, ahogy írtam.
    Mutasd a teljes hozzászólást!
  • és durva is lenne ha a webről érkezett rendelések ellenőrzés nélkül csesztetnék a készletet.

    Attól hogy neked fóbiád van a webbel kapcsolatban , egyáltalán nem durva az, hogy ha valamit eladtam, akkor az már nem a készlethez tartozik. Te eladnád még egyszer, vagy a lokális eladás előtt lekérdezed a webszervert hogy ugyan nem adta-e már el?
    Ha meg c# mellett PHP-hoz nyúlsz (ASP helyett), akkor aztán tényleg csinálhatod 2x az egészet, ha nem a db-be rakod
    Mutasd a teljes hozzászólást!
  • Sztem is a biztonság a legfontosabb. Sőt, egy általam tökéletesnek vélt rendszerben az adatbázis menedzser az egyszerű halandó programozónak a tárolt eljárások hívásán kívül semmi jogot nem biztosítana éles környezetben.

    A wrapper függvényt/objektumot is hasznosnak (sőt, szinte kötelezőnek) tartom, mégpedig mások által felsoroltakon kívül olyan szempontból is, hogy a program a tárolt eljárásoknak a wrapper függvényben definiáltakon felül sok egyéb paramétert is átadhat. Pl. a naplózáshoz elengedhetetlen felhasználó-azonosítót, leírásokat stb. Ekkor felesleges ezeket paraméterben előirányozni.

    Mondjuk érdekes vitakérdés a naplózás maga is, hol érdemesebb őket tartani?
    Mutasd a teljes hozzászólást!
  • Ha van egy üzleti objektumod, a feladatokat neki kell elvégeznie. Pl. a bizonylat objektumod ha kap egy új tételt (vagy egy tételt módosítasz) akkor ő gondoskodik az összeg számításáról. Akár a kliensen is ha épp ott tartózkodik. De ehhez nem kell a szerverhez fordulni - különben is, korántsem biztos hogy végül minden üzleti objektum bekerül az adatbázisba. Egy bizonylatot el is lehet dobni. És ha az összeget külön algoritmus számolná az usernél amikor felviszi a bizonylatot, és külön trigger a BL-ben amikor felírtad - na az lenne inkozisztens gányolás. Fontos szempont, hogy egy adott dolgot lehetőleg ugyanaz az algoritmus számoljon mindig, lehetőleg ugyanabban az objektumban. Na ennek mond ellent az RDBMS-be rakott BL. Néha használunk ilyet mert gyors, de ez bizony a legtöbb esetben gányolás.
    Mutasd a teljes hozzászólást!
  • Ha több ezer géped van az már alkalmazásszerver. És ha sokszor kell település távolságot számolnod akkor jobban jársz egy mindig a RAM-ban tartott csomópont-él objektumhalmazzal mint ha a tárolt eljárás szedegetné elő minden híváskor az adatbázisból.
    Mutasd a teljes hozzászólást!
  • Mindenképp célszerű egy köztes réteg, de ennek nem az RDBMS-ben a helye - kivéve az extrém sebességkritikus részeket.

    A webshop amúgy is külön téma. Míg az éles eladásoknak a lokális szerveren a helyük, addig a webshop általában egy webhostingnál van valami szutyok php script formájában ami az ottani mysql adatbázisban tartja az adatokat. A kettő nem ugyanaz, és durva is lenne ha a webről érkezett rendelések ellenőrzés nélkül csesztetnék a készletet.
    Mutasd a teljes hozzászólást!
  • Ettől még igen összetett üzleti logikai feladatot oldhatsz meg a kliens rétegén, ha szükséges.

    Aminek bármi köze van a db-hez, azt a legkevésbé ott célszerű. Most maradjunk a készlet kezelésnél. Mennyire jó megírni az asztali kliensen (értékesítő hely) és utána a webes szerveren (webshop). Mindenképp célszerű egy köztes réteg, én azt az SP-be, triggerekbe tenném. Van aki egy teljesen új réteget hoz létre. Csak ebben az esetben nem állja meg a helyét az a pár pont, amivel interpet elindította ezt a vitát. Mert se nem olcsóbb, se nem gyorsabban előállítható, se nem szállíthatóbb a kód, az meg vita tárgya hogy kinek mi az elegáns.
    Mutasd a teljes hozzászólást!
  • Sting, te kategórikus kijelentéseket tettél (mindig, csak)
    Idéznél?


    Nagyon szívesen!

    A másik - bár a fentivel összefüggő - dolog, hogy a C#-ból kiadott utasításokat szerencsétlen adatbázisszervernek mindig újra kell értelmeznie,


    Nem stimmel, mert ugye a prepared statement-ek esetén csak egyszer fogja ezt a feladatot végrehajtani a szerver. Igen, a prepared statement-ek használhatósága korlátozott, de a mindig akkor sem állja meg a helyét.

    A harmadik dolog, hogy a C#-ból csak egyirányban tudsz kommunikálni az adatbázisszerverrel, az közvetlenül nem tud a te üzleti logikádba visszahívni vagy téged az adatbázisban bekövetkezett specifikus változásokról értesíteni.


    Ez db függő, ahogy írtam is rá példákat. Tehát a csak megint nem állja meg a helyét.

    Ez 2 olyan kategórikus kijelentés volt a részedről, amelyek szimplán nem állják meg a helyüket. Amikor pedig arról megy a vita, hogy egy adott esetben mi a hatékonyabb megoldás kód vagy tárolt eljárás, akkor ezekről a tényezőkről sem szabad elfelejtkezni.
    Mutasd a teljes hozzászólást!
  • "A tárolt eljárások nyelvei finoman szólva nem feltétlenül arra lettek kitalálva hogy komplex algoritmusokat valósíts meg bennük átlátható módon."


    Ez teljesen igaz, vagyis lassan elérünk oda, hogy tisztázhatóak a dolgok.

    Ellenőrzések és alapvető (üzleti) szabályok betartása nem szakítható el a DB szintjétől.
    De hát erre találták ki a rétegezést!

    Pl. egy kérdés, hogy van-e a készleten kiadható mennyiség?
    Ez üzleti logika? Egyértelműen, de ez adott esetben igen bonyolult lehet (pl. foglalások kezelése vagy raktárközi mozgatással kiadható mennyiség biztosításának lehetősége).
    [Arról nem beszélve, hogy akár ügyfelenként egyedi extra feltételek is bejöhetnek ]

    Vagy a DB-be kell tenni, vagy legalább 3 réteget alkotni, ahol az adatbázishoz fizikailag csak a közbenső rétegen keresztül lehet elérni (ami logikailag még mindig az "adatbázisban van"-nak felel meg).

    Ettől még igen összetett üzleti logikai feladatot oldhatsz meg a kliens rétegén, ha szükséges. De egy SMS-ben küldött kérdésnél könnyű a válasz megoldása, de főként konzisztens.
    Mutasd a teljes hozzászólást!
  • "És általában egy üzleti logikát nem olyannak kell bogarásznia aki a programnyelvet sem ismeri."


    Moduláris felépítésről hallottál már?
    A DB+Triggerek+SP-k együtt egy jól tesztelt, működő egészet kell alkossanak.
    Ne keverjük az elérési/kezelési kliens alkalmazásokkal.
    [Mert bár ma már a c# vagy java nagymértékben segít, de még mindig igaz, hogy adott esetben számos módon módosulhat az adatbázisod. Akár több platformról sokféle (akár más-más részfeladatokat végző) kliens program, weben/honlapon keresztül, okostelefonról, sms-ben, importokkal, szervizeken keresztül stb.]

    Hagyjuk az adatbázist, hogy tegye a dolgát. Tételezzük fel (hogy a tervszerűen belevitt mértékű) üzleti logikát korrekten, tesztelten elvégzi. Aztán erre, mint biztos alapra építjük (egy valódi! programnyelven) a klienst, ami egy újabb üzleti logika réteget tehet hozzá, értelem szerűen lényegesen összetettebb dolgokat is akár, de nem léphet túl a DB-ben megírt alap logikán.

    Pl. Adott esetben a mozgások triggerrel karbantartják a készletet és ez nem csúszhat el. Vagy ha a számlafejben összesent tárolunk, akkor azt a tételek beszúrása hozza létre, vagy egy SP szúrja be a tételeket és gondoskodik a redundáns adat helyességéről. Erre mint axiomára lehet támaszkodni. Ha ez egy alap szabály, akkor soha nem vehető ki a DB fennhatósága alól! Onnan gányolássá válik a dolog.
    Mutasd a teljes hozzászólást!
  • "Az elmélet és a gyakorlat közt az a különbség, hogy elméletileg nincs köztük különbség, gyakorlatilag meg van".


    Szerintem elméletileg is van, azaz ez egyén függő lehet. Legalábbis, én mindig úgy gondolok valamire, hogy szép és jó az elv, de gyakorlatban úgyis tuti lesz szívás, mert sok minden lehet, amire nem is gondoltunk, mint lehetséges probléma. Ráadásul sok olyan tényező van, amire nincs hatásunk/rálátásunk teljes egészében.
    Azaz én biztos vagyok benne, hogy az elv és a gyakorlat között lesz különbség, azaz az én elméletemben mindig lesz különbség az elmélet és gyakorlat között :)
    Mutasd a teljes hozzászólást!
  • Ez így van, nem biztonságos 100%-ig (rendszergazdák töltögetik a pornót, ismerősöknek engedélyezik az újabb flashplayert, admin jogokat a gépen, stb), de az elvben szó is volt LC mondatában :)

    "Az elmélet és a gyakorlat közt az a különbség, hogy elméletileg nincs köztük különbség, gyakorlatilag meg van".
    Mutasd a teljes hozzászólást!
  • Ez architektúrától függ. Egy lokális hálózaton a kliens és a szerver közt elvben nem lehet megbízhatatlan gép.

    Már hogyne lehetne. A kliens felől érkező adat mindig megbízhatatan, helyi hálózaton is, hiszen legkésőbb a hálózati fizikai szinten manipulálhatók az áramló adatok - a hálózat egészét pedig lehetetlenség tökéletesen védeni. Persze titkosítással, hitelesítéssel lehet ilyesmik ellen megpróbálni védekezni, de azzal nehéz lenne vitatkozni, hogy sokkal egyszerűbb a rendszer integritását megvédeni, ha azt csak egy ponton (ti. az adatbázisszerveren) kell megtenni, és nem a tipikusan minimum többszáz, többezer csomóponttal rendelkező helyi hálózat egészén, ami ráadásul gyakorlatilag sosem alkot végig hitelesítési láncba fűzött zárt rendszer (ti. ami egészen a billentyűzettől és az egértől kezdve érkező adatokon át a programokon át a hálózati meghajtók firmware-jéig hitelesítve és így védve lenne legalább elméleti szinten a manipulációval szemben; és ha nem az bármelyik eleme is, akkor azon, mint leggyengébb elemen keresztül az egész rendszer támadhatóvá, ezen keresztül pedig a kliens megbízhatatlanná válik).

    Az tény hogy így is közlekednek adatok a BL és az SQL szerver közt, de ez általában azért nem generál annyira nagy forgalmat mivel egy-egy objektumot kell csak előszedni.

    Az, hogy hány és mekkora adatot kell előszedni, kizárólag az alkalmazás függvénye, meg azé, hogy az adott adatbázisszerver milyen magasszintű műveleteket támogat, ill. az adatszerkezetet mennyire sikerül ehhez igazítani, optimalizálni. Ha pl. az adatbázisszerver nem tud GPS koordináták között távolságot számolni beépített függvénnyel és/vagy nem tud számított mezőre indexelni, akkor bizony mondjuk egy adott ponthoz legközelebbi helység meghatározásához az összes település adatait át kell passzírozni az adatbázisszerverből az üzleti logikába, míg ha tárolt eljárásban le tudod ugyanezt kódolni, akkor csak egyetlen egy sort kell visszaadni.
    Mutasd a teljes hozzászólást!
  • Sting, te kategórikus kijelentéseket tettél (mindig, csak)

    Idéznél?
    Mutasd a teljes hozzászólást!
  • Sting, te kategórikus kijelentéseket tettél (mindig, csak), én rámutattam, hogy a kategórikus kijelentéseid nem jók, mert léteznek olyan lehetőségek, technológiák, amelyek igenis ellentmondanak a sarkos véleményednek.

    Az értesítésre adott válaszod meg csak a postgresql szempontjából igaz, az oracle és mssql szempontjából meg nem. Az meg, hogy mi primitív és mi nem, igencsak izlés kérdése.
    Mutasd a teljes hozzászólást!
  • Mert egy helyi hálóban ha már megbízhatatlan gép van, akkor jó eséllyel az adatbázishoz is hozzáférnek, azaz lényegében teljesen mindegy.


    Hát azért nem teljesen. Azért még el kell jutni odáig, hogy meghekkeljen mindent. Gondolom nem kap domain usert az megbízhatatlan gépet használó felhasználó, vagy csak egy eléggé korlátozottat, ha szükséges.
    Mutasd a teljes hozzászólást!
  • Azért erre a feltételezésre nem építenék biztonsági rendszert...
    Pláne, manapság, mikor a laptop már szinte nélkülözhetetlen kellék.
    Mutasd a teljes hozzászólást!
  • Mert egy helyi hálóban ha már megbízhatatlan gép van, akkor jó eséllyel az adatbázishoz is hozzáférnek, azaz lényegében teljesen mindegy.
    Mutasd a teljes hozzászólást!
  • Hm... ha a rendszergazdák pornót töltögetnek, az már rég rossz...


    Pedig töltögetik, hidd el ;)

    Nem erre gondoltam, de a részletekbe nem mennék bele. Aki látott ilyesmit, az úgyis tudja, miről beszélek.


    Mámint milyet? Hogy nem biztonságos egy hálózat, és széthekkeltek valamit?
    Mutasd a teljes hozzászólást!
  • Hm... ha a rendszergazdák pornót töltögetnek, az már rég rossz...
    Nem erre gondoltam, de a részletekbe nem mennék bele. Aki látott ilyesmit, az úgyis tudja, miről beszélek.
    Mutasd a teljes hozzászólást!
  • Még egy bankban sem merném kijelenteni, hogy a kliens és a szerver közt 100%-ig biztonságos a hálózat.


    Ez így van, nem biztonságos 100%-ig (rendszergazdák töltögetik a pornót, ismerősöknek engedélyezik az újabb flashplayert, admin jogokat a gépen, stb), de az elvben szó is volt LC mondatában :)
    Mutasd a teljes hozzászólást!
  • Még egy bankban sem merném kijelenteni, hogy a kliens és a szerver közt 100%-ig biztonságos a hálózat. Esetleg szerverek közt... de ott is csak esetleg és 1000 feltétel függvényében. (és ezzel nem is vagyok túl paranoiás )
    Mutasd a teljes hozzászólást!
  • Hát bankokál rögtön jön a bankbiztonság, ha érzékelik, hogy egy laptopot rádugnak a hálózatra.
    De egy kisebb (sok nagyobbnál sem) cégnél vszeg nincs ilyen security
    Mutasd a teljes hozzászólást!
  • Egy lokális hálózaton a kliens és a szerver közt elvben nem lehet megbízhatatlan gép.


    Ebben miért vagy biztos?
    Mutasd a teljes hozzászólást!
  • Mivel pl nem lehet EF-el ilyen utasítást kiadni, hogy update akarmi set akaremi = 3 where ....

    EF4-ben már elvileg lehet (nem próbáltam), van ExecuteStoreCommand függvény.
    Mutasd a teljes hozzászólást!
  • Ha pedig valamit tömegesen kell csinálni, akkor még mindig ott a globális update parancs amit a data access layer felől is ki lehet adni.


    Azért összetettebb nagymennyiségű adatfeldolgozásra az sem elég sajnos. Példa a szokásos import: Adnak egy excelt, amelyben 5-6 tábla adatai vannak összerakva egy-egy sorba. Ezeket kell szétszedni, mindenféle vizsgálatot ráfuttatni, referenciákat ellenőrízni (nem id alapján), stb.
    De már találkoztam olyannal is, hogy egy db excel táblázatban 3-4 táblázat volt, és azok függtek egymástól, na ott erőltették, hogy ef-el legyen megoldva, persze olyan is lett nagy adatmennyiségnél. Már nem emlékszem pontosan az esetre, de ahhoz, hogy valamit megcsináljunk vele, példányosítani kellett egy rakás entitást, amit sql-ben simán meg lehetett volna oldani.
    Ezekben az esetekben szerintem is érdemes egy(vagy több) sp-t alkalmazni.
    Mutasd a teljes hozzászólást!
  • Ez architektúrától függ. Egy lokális hálózaton a kliens és a szerver közt elvben nem lehet megbízhatatlan gép. Ha viszont alkalmazásszerverben gondolkodsz (és miért ne tennéd) akkor az üzleti logika nyugodtan lehet akár az adatbázisszerveren is, a kliensek és az alkalmazásszerver között pedig lehet mondjuk egy wcf. Az tény hogy így is közlekednek adatok a BL és az SQL szerver közt, de ez általában azért nem generál annyira nagy forgalmat mivel egy-egy objektumot kell csak előszedni. Ha pedig valamit tömegesen kell csinálni, akkor még mindig ott a globális update parancs amit a data access layer felől is ki lehet adni.
    Mutasd a teljes hozzászólást!
  • Ha így illene, akkor nem jönne azzal LC, hogy "de hát C#-ba közvetlenül be tudom írni az SQL-t a kódba".


    Ennek semmi köze szvsz ahhoz, hogy szolgáltatást alapú architektúrát készít valaki, vagy oldstyle mindenki eléri a db-t jellegűt. A szervíz adatelérési rétegébe is lehet ilyet művelni. Amúgy meg sztem nem sqlt ír a kódba, hanem valamilyen orm által biztosított lekérdező függvényeket, linq kifejezéseket használ, ami persze sql utasításként pottyan ki az sql szerver felé. Mondjuk személy szerint az újabb ms-es adatelérési technológiákat (linq to sql, ef) nem szeretem, mert több velük a probléma, mint amennyi hasznot hoznak. Az átalakított sql utasítások teljesítménye sem mindig az igazi.

    Nem mintha tényleg igaz lenne, hogy "ezt így illik csinálni"


    Mért nem?

    Természetesen, ha webes alkalmazást fejleszt valaki, akkor az esetek nagy részében nics szükség a szervíz rétegre, mert minden szerveroldalon van.

    Viszont te azt az esetet említetted, hogy a c# kódok a klienseken futnak (
    mivel a C# kódok a kliens oldalon futnak
    ), kvázi ha jól értettem winform - adatbázis jellegű architektúrára értetted, amit mondtál.
    Nem nagy plusz munka egy szervízréteget felhúzni az üzleti logika felé, cserébe rengeteg előnnyel jár.

    vagy hogy ez a ".NET-es körök" sajátsága lenne


    Ezt nem is állítottam, hogy sajátossága. Csak azért írtam, mert c# kódot emlegettél...


    Ugyanakkor erre a megoldásra továbbra is igazak a korábban írt hátrányok például a lekérdezések előfordításával, a kommunikációs overheaddel, stb. kapcsolatban írtak. Ami persze nem azt jelenti, hogy nem lehet értelmes vagy indokolt ennek a megoldásnak a használata, csak azt, hogy ez nem tekinthető kvázi ekvivalensnek a tárolt eljárások használatával, és utóbbiak nem helyettesíthetők vele minden körülmények között.


    Nyilván ez így van. A szokásos példám az import :) Mivel pl nem lehet EF-el ilyen utasítást kiadni, hogy update akarmi set akaremi = 3 where ...., ezért teljesítmény szempontjából ilyen feladatokra alkalmatlan. NHibernate-el emlékeim szerint viszont lehet :)
    De egyértelmű, hogy ilyen eseteknél a teljesítmény az elsődleges.
    Mutasd a teljes hozzászólást!
abcd