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-06-30T12:13:16+02:00
  • Persze, lehet SP-be magas szintű nyelven írni, de azért a hibakezelés nem túl elegánsan valósítható meg szerintem és bizonyos esetekben a tranzakciókezelés is problémás lehet(nem csak db tranzakcióra gondolok, hanem mikor egy insertet egy másik művelettel kell tranzakcióban kezelni). Valamint ha az ügyfél azt mondja, hogy lecserélem az eddigi PostgreSQL-t Oracle DB-re, akkor azért nem szívesen írnám át/gondolnám újra az összes DB logikát. Azért egy ilyen eset nem szokatlan.
    Mutasd a teljes hozzászólást!
  • Tulajdonképpen miért idézed be a kérdést amit írtam, ha nem arra válaszolsz?

    Egyébként meg a "limitált képességű stored proc sql"-ről annyit, hogy pl. PostgreSQL-ben Perl-től kezdve Python-on át a Java-ig egy tucat magasszintű nyelven írhatsz tárolt eljárásokat, de az Oracle PL/SQL-je is ismeri a sturktúrált kivételkezelést, lehet benne objektumokat deklarálni mezőkkel, metódusokkal, stb.

    Ha ez nem elég ahhoz amit meg akarsz írni a tárolt eljárásokba, akkor azokat valószínűleg nem is azokba kell belepaszírozni, hiszen már közük nincs az adatkezelési réteghez, hanem valami jóval magasabb szintű üzleti logikai részt valósítanak meg, amiknek semmi helyük a tárolt eljárásokban. Ha meg mégis, akkor a kritikus kódokat megírhatod kedvenc magasszintű nyelvedben (C#, Java, akármi) és bővítésként, felhasználói függvényként betöltve tudod használni az adatbázis tárolt eljárásaiból is. Erre szintén minden épkézláb adatbáziskezelő lehetőséget ad.
    Mutasd a teljes hozzászólást!
  • az alkalmazásszerver mennyiben oldja meg az itt az üzleti logika részét képező tárolt eljárásokkal szemben ultima ratio-ként felhozott érveket, problémákat, hogy ti. "de hát azokat akkor külön meg kell írni", meg hogy "nehézkes a karbantartása, és nem lehet beledebugolni", stb. Mert ugye az alkalmazásszervert is külön meg kell írni, és mert abba sem lehet csak úgy szépen, transzparens módon átdebugolni a legtöbb nyelven/platformon/fejlesztőeszközben, ahhoz sem kapsz integrált hivatkozási keresztreferenciát a kliensalkalmazással, stb. Továbbra is várom a választ erre a kérdésre.


    Ha meg is kell írni, de egyszer kell. Azaz az adatbázisspecifikus részek legrosszabb esetben is csak a data access layerben fordulnak elő. Ráadásul normális, magas szintű nyelven írhatod, és nem az igencsak limitált képességű stored proc sql-ben. Ráadásul a SP-ben megírt BL értelemszerűen csak a letárolt adatokon, és csak szerveroldalon fut. Azaz, ha szeretnél olyan funkcionalitást a BL-ben ami nem letárolt üzleti objektumon, kliens oldalon is végre kell hogy hajtódjon, akkor ezt RDBMS-ben megírva minimum redundanciához vezet.

    Én mostanság alapjában véve .net fejlesztő vagyok, nekem nem gond átdebuggolni az alkalmazásszerverre. Szvsz java esetén is megoldható a dolog, bár ezzel ilyet még nem csináltam. Másban viszont nem kezdenék ma olyan méretű és jellegű rendszert ahol ez szempont lehet.

    Ezzel együtt én azt mondom, lehet értelme az üzleti logika egy részét BL-be rakni, de leginkább csak a nagyon sebességkritikus részeket. Igazából ez az attól is függ, milyen feladatot oldasz meg. Más egy dobozos ügyviteli szoftver, és más egy egyedi nagyforgalmú webalkalmazás.
    Mutasd a teljes hozzászólást!
  • Ok, igazad van, tévedtem részemről téma befejezve.
    Mutasd a teljes hozzászólást!
  • Ez volt az eredeti szöveg, és ebből találta ki Sting, hogy én azt gondolom jobb az üzleti logikát nem egy szervíz mögött kezelni.

    Nem találtam én ki semmit - csak egyszerűen felhívtam a figyelmed a tényre, hogy mindezek a pontok gyakorlatilag ugyanabban a formában igazak az alkalmazásszerverekre is. Ergo, ha te fenntartod, hogy ezek negatívumok és emiatt mindenáron kerülendők, akkor nem érvelhetsz az alkalmazásszerver mellett, mert akkor a pontjaid alapján az is csak plusz fáradtságot, nehézséget és munkát jelentő megoldást képez a jó kis monolitikus klienshez képest. Ha meg mégis az alkalmazásszerver potenciális hasznossága mellett foglalsz állást, akkor azzal elismered, hogy ezek a kifogásaid általánosságban teljesen alaptalanok voltak.

    Rád bízom, hogy melyik mellett döntesz (ti. hogy anno mondtál hülyeséget ezekben a pontokban, vagy akkor, amikor az alkalmazásszervert ennek ellenére pozitívnak találtad), de a kettő együtt nem megy.
    Mutasd a teljes hozzászólást!
  • Aha. Direkt linkelek, hogy mindenki ellenőrizhesse, utánanézhessen, direkt azért, hogy a többiek ne lássák és ne olvashassák el, mert akkor "lebukok". Logikus. Csak úgy, mint a tárolt eljárások elleni érvelésed is...
    Mutasd a teljes hozzászólást!
  • Ez volt az eredeti szöveg, és ebből találta ki Sting, hogy én azt gondolom jobb az üzleti logikát nem egy szervíz mögött kezelni. A kérdés ugye az volt, hogy mért ne sp-be rakjuk az üzleti logikát...

    Hát több okból:
    1) Nem oda illik az üzleti logika

    2) Nehezebben átlátható. Egy bonyolultabb logika esetén, honnan tudod, melyik sp van használva, és melyik szemét, főleg, ha egymást, plusz function-öket hívogatnak, stb?

    3) Több helyen kell keresgélni a fejlesztőnek, hogy mi is történik, míg ha egyszerű adatelérésre használja valaki, akkor az adatbázishoz szinte hozzá sem kell nyúlni fejlesztési időben. Amúgy meg valamit átírnak a kódban, aztán az sp-t is túrják kicsit.

    4) Minél több helyen van logika annál nehezebben karbantartható, főleg egy nem azzal a projekttel foglalkozó fejlesztőnek.

    5) Sok gányoláshoz vezethet. Pl végig kell menni egyesével egy adathalmazon, ezért kurzort használnak, stb. Tipikusan szoktak string összerakással sql parancsot is készíteni sp-kben, ami sqlinjection-re biztos nagyon jó! ;)

    6) Szükség esetén nehezebben portolható az alkalmazás más adatbázisra.

    7) Nincs olyan mértékű támogatás fejlesztési időben, mint egy normális fejlesztőeszköz esetén. Pl nem igazán kapunk mindig hibát egy sp létrehozáskor, ha az le sem futna futásidőben.

    8) Az egymásra hivatkozó sp-kre, function-ökre szintén nem kapunk "fordítás idejű hibát"

    9)....

    10) Dolgozok inkább :)
    Mutasd a teljes hozzászólást!
  • Nem, bocs, de Sting már reagált is egy linkkel (ami most gondolom direkt azért nem idézet, mert akkor a többiek is elolvasnák, és látnák, hogy megint b@romságot írt)...
    Mutasd a teljes hozzászólást!
  • Ö... ez biztos, hogy nekem szól?
    Mutasd a teljes hozzászólást!
  • Honnan vetted, hogy azt gondolom, nincs értelme szerveroldalon tartani kézben az üzleti logikát?

    Onnan, hogy mindaz amit itt kifogásként megfogalmaztál igaz bármilyen megoldásra ami szerveroldalra emeli át az üzleti logika egy részét - legyenek azok tárolt eljárásokban vagy egy dedikált alkalmazásszerverben. Utóbbi megírása is úgymond plusz munka, az eredmény platformfüggő, nem nyomkövethető a kliens alkalmazással egyben, nem kapsz hivatkozási keresztreferenciát a kettőre, nem kapsz fordítási idejű hibát ha az alkalmazásszerver és a kliens által alkalmazott interfész verzióiban eltérés keletkezik, stb.

    Ezen nincs mit tovább magyarázni. Ill. azt kellene vagy lehetne beismerni, hogy tévedtél, vagy hogy közben tanultál és meggyőztek, hogy mégsem ördögtől való ha nem (csak) egy kliensoldali binárisban van az egész üzleti logika - de úgy látom ehhez abszolút nem fűlik a fogad. Te tudod...
    Mutasd a teljes hozzászólást!
  • Aha. Tehát akkor ezek szerint mégis van értelme az üzleti logika egy részét kiemelni és szerveroldalra átvinni (pl. tárolt eljárásokba), hogy egy ellenőrzött "szolgáltatási homlokzaton keresztül tudd kiajánlani a kliensek felé".

    Tudod egyáltalán még milyen álláspontot képviselsz és mi mellett akarsz kardoskodni, vagy mindegy, csak mondj ellent?


    Honnan vetted, hogy azt gondolom, nincs értelme szerveroldalon tartani kézben az üzleti logikát?

    Ha vetted volna a fáradtságot, és értelmeznéd is amit más írt, és nem csak ellentmondanál, és nyomnád az okosságaid kisregényekben, illetve sértegetnél másokat (már kitaláltad, hogy csak mysqlt használtam, nem ismerek semmilyen adatbázisszervert, nem tudom milyen állásponton vagyok, odbc-t használok???, stb.) akkor talán értenéd, hogy annyit írtam összesen, hogy az üzleti logika nagy részét véleményem szerint nem tárolt eljárásokban kéne tartani. Ennyit jelentettem ki és pont.

    A fenti kijelentésed megint nem tudom hogy raktad össze, de lassan már biztos azt is tudod, hogy rózsaszínű bugyit hordok...
    Mutasd a teljes hozzászólást!
  • Az alkalmazásszerver azt jelenti, hogy a BL-ed ott csücsül az adatbázisszervered felett, és kommunikál a kliensekkel. [..] Ps: Commodore 64-gyel nem vezérlünk atomerőművet, és PHP-ben nem keresünk útvonalat.

    Neked is leírom, hogy nem az volt a kérdés, hogy definiáld mi az alkalmazásszerver, vagy hogy C64-gyel vezéreljünk -e atomerőművet, hanem hogy írd meg, hogy az alkalmazásszerver mennyiben oldja meg az itt az üzleti logika részét képező tárolt eljárásokkal szemben ultima ratio-ként felhozott érveket, problémákat, hogy ti. "de hát azokat akkor külön meg kell írni", meg hogy "nehézkes a karbantartása, és nem lehet beledebugolni", stb. Mert ugye az alkalmazásszervert is külön meg kell írni, és mert abba sem lehet csak úgy szépen, transzparens módon átdebugolni a legtöbb nyelven/platformon/fejlesztőeszközben, ahhoz sem kapsz integrált hivatkozási keresztreferenciát a kliensalkalmazással, stb. Továbbra is várom a választ erre a kérdésre.

    É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.

    Nagyon jó, csak kár, hogy ez tárolt eljárásokra alapozott üzleti logika használata esetén is így van. Szóval azok kívül, hogy sikerült csomó irreleváns evidenciát elpuffogtatnod, ezzel sem mondtál semmi érdemi érvet a tárolt eljárásokkal szemben.
    Mutasd a teljes hozzászólást!
  • Mondjuk az is igaz, hogy csak az általam ismert rendszereket vettem alapul: vagy webes volt vagy vastag kliens+alkalmazás szerver... Olyannal nem találkoztam, hogy web+alkalmazás szerver.
    (vagy csak nem emlékszem)
    Mutasd a teljes hozzászólást!
  • Nem akarok hülyeséget írni, meg visszaolvasni se fogom a kisregényeket, de szte te kezdted azt az esetet feszegetni, hogy a c# kódok kliensen futnak :)

    Látod, ha vetted volna a fáradtságot, és visszaolvastál volna, akkor rájöttél volna, hogy ebben is tévedsz.

    "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."
    Így van, ezért szokták az üzleti logikát kiajánlani egy szolgáltatási homlokzaton keresztül a kliensek felé.

    Aha. Tehát akkor ezek szerint mégis van értelme az üzleti logika egy részét kiemelni és szerveroldalra átvinni (pl. tárolt eljárásokba), hogy egy ellenőrzött "szolgáltatási homlokzaton keresztül tudd kiajánlani a kliensek felé".

    Tudod egyáltalán még milyen álláspontot képviselsz és mi mellett akarsz kardoskodni, vagy mindegy, csak mondj ellent?
    Mutasd a teljes hozzászólást!
  • Miért jó hogy nem közvetlenül az adatbázissal komunikálok? Mitől véd meg ez engem,

    Akkor ezt nem értem...
    Na mind1. Mondom, hogy az előzményeket nem olvastam.
    Mutasd a teljes hozzászólást!
  • Például attól véd, hogy valaki a programod helyett egy megfelelő kliensből beleszemeteljen az adatbázisodba. Némi routing, tűzfalazás, ilyesmi és az adatbázisodat kizárólag az alkalmazásszerveren keresztül tudja elérni a kedves felhasználó még akkor is, ha egyébként valahonnan megtudja a szükséges usernevet, jelszót, egyéb authentikációs infót.

    Az volt a kér(d)és, hogy miben több és jobb az alkalmazásszerver/webszervíz, mint az ugyanazt a funkcionalitást biztosító tárolt eljárások használata. Nem az, hogy sorold fel azt, hogy miben azonosak.
    Mutasd a teljes hozzászólást!
  • Az hogy neked csak olyan esetek jutottak hogy a webservice közvetlenül írt az adatbázisba max. annak lehet a következménye hogy az illetőnek aki a rendszer tervezte nem erőssége az OOP. Ami mondjuk a PHP és vidéke környékén nem annyira ritkaság, a PHP a 4.0 óta kezdett OOP lenni, de a rendszer API-nak (már ha azt a pár száz összehányt függvényt lehet ennek nevezni) még ma sem sok köze van hozzá.
    Mutasd a teljes hozzászólást!
  • Bocsi, de ezek szerint nem ismered se az mssql-t, se az oracle-t. Nincs szükség semmilyen pollozásra és nem is szimplán az egyik kliens küld eseményt a db-n keresztül egy másiknak (bár arra is lehet használni, ha nagyon akarja valaki).

    Légyszi' mutass már erre egy példát, vagy linkeld minimum az idevágó SQL kulcsszót, API-t, mert azok nélkül ezek idáig csak levegőben logó, ellenőrizhetetlen kijelentések.
    Mutasd a teljes hozzászólást!
  • Például attól véd, hogy valaki a programod helyett egy megfelelő kliensből beleszemeteljen az adatbázisodba.
    Némi routing, tűzfalazás, ilyesmi és az adatbázisodat kizárólag az alkalmazásszerveren keresztül tudja elérni a kedves felhasználó még akkor is, ha egyébként valahonnan megtudja a szükséges usernevet, jelszót, egyéb authentikációs infót.

    És nem feltétlenül téged véd, hanem a megbízódat, az ő rendszergazdáját, ilyesmi...

    @interpet2: most sem olvastam el az előzményt!
    Mutasd a teljes hozzászólást!
  • Elkezdtem válaszolni, de egy oldal után abbahagytam, mert rájöttem kár írni, ez egy elvi vita, és nem hiszem, hogy bármelyikünk meggyőzné a másikat :)
    Mutasd a teljes hozzászólást!
  • Bocs, de ez csak öncélú kötözködés részedről.


    Nem, nem öncélú kötözködés a részemről, hanem rá akartam világítani, hogy az érvelésed pontatlan. Igen, én is szoktam kategórikus kijelentéseket tenni és nem egyszer az orromra is koppintanak miatta mások itt a prog.hu-n, ahogy most ez veled is megtörtént. Speciel a három idézeted roppant gyenge, de gondolom, nem vetted a fáradságot a hozzászólások átolvasássára...

    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.


    Bocsi, de ezek szerint nem ismered se az mssql-t, se az oracle-t. Nincs szükség semmilyen pollozásra és nem is szimplán az egyik kliens küld eseményt a db-n keresztül egy másiknak (bár arra is lehet használni, ha nagyon akarja valaki). De ha lusta vagy utána nézni, az nem az én bajom.
    Mutasd a teljes hozzászólást!
  • Van ahol nem cél a minél több hibalehetőség. Én ezt az egész websevices dolgot a programozók agyament játszadozásának tartom. Miért jó hogy nem közvetlenül az adatbázissal komunikálok? Mitől véd meg ez engem, amikor ezt a közbenső réteget is én írom és én irom a klienst is, ami ehhez a közbenső réteghez csatlakozik?
    Természetesen programozóként (oh, bocsánat, phpzóként ) én is írtam már servicet és servicehoz tartozó klienst is. Nem is egyet, de még olyan esetbe nem futottam bele, amikor nem az volt a feladat, hogy az adatbázisba írjak, vagy onnan olvassak. Az egyenlet magyarázat, ami miatt az üzleti logikát sem tudod elképzelni az adatbázisban:
    nem elegáns
    . De miért is elegánsabb egy webservice? Ott a 80-as portot kell megnyitni, míg például egy mysqlnél a 3306-os portot. Ugyanúgy le tudom védeni a táblákat, ahogy a szolgáltatást is (csupán jelszó). Ugyanúgy lehet titkosítani ssh-val. Nyilván ha én csak magát a szolgáltatást ajánlom ki, akkor lehet benne ráció, de hogy a saját kliensem a saját webserviceommal kommunikáljon, az nekem agyament...
    Mutasd a teljes hozzászólást!
  • Amúgy az MA még nagyobb dőreség, hogy csak az adatbázisszerverre bízza valaki az üzleti logikát, és több ezer kliens közvetlenül az adatbázist érje el...


    Mielőtt beleköt valaki, kicsit rosszul, és gyorsan fogalmaztam! :)
    A lényeg, hogy ne az adatbázist piszkálják közvetlenül a kliensek, hanem egy szolgáltatáson keresztül érjék azt el.
    Mutasd a teljes hozzászólást!
  • Nyilván, de próbáld meg azért elolvasni az előtte lévő hozzászólásokat, ne mindig csak az utolsóra reagálj. :)

    Erre próbáltam válaszolni:
    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.
    Mutasd a teljes hozzászólást!
  • Abból, hogy az üzleti logika (nagy része) tárolt eljárásokban van, még nem következik feltétlenül, hogy a kliensek közvetlenül az adatbázishoz kapcsolódnak. Szerintem.
    Mutasd a teljes hozzászólást!
  • Amúgy az MA még nagyobb dőreség, hogy csak az adatbázisszerverre bízza valaki az üzleti logikát, és több ezer kliens közvetlenül az adatbázist érje el...
    Mutasd a teljes hozzászólást!

  • Apropo, "PHP nem programnyelv" - ebben valahol egyetértünk.
    Tudna valaki olyan, free tárhelyet, ahol a PHP-n kívül van egyéb lehetőség is? (ruby, python, netán java servlet)
    Mutasd a teljes hozzászólást!
  • 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.


    Nem akarok hülyeséget írni, meg visszaolvasni se fogom a kisregényeket, de szte te kezdted azt az esetet feszegetni, hogy a c# kódok kliensen futnak :)

    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.


    Így van, ezért szokták az üzleti logikát kiajánlani egy szolgáltatási homlokzaton keresztül a kliensek felé.
    Mutasd a teljes hozzászólást!
  • Tartok tőle, a C64 korszerűbb gép, mint az, ami Paksot irányítja.
    Mutasd a teljes hozzászólást!
  • Ps: Commodore 64-gyel nem vezérlünk atomerőművet, és PHP-ben nem keresünk útvonalat. Ahogy az ősi székely mondás tartja: az asszony nem ember, a medve nem játék, a PHP meg nem programnyelv.
    Mutasd a teljes hozzászólást!
abcd