Az ORM megoldások nehézségeiről és arról, hogy nem lehet nem tudomást venni a mögöttük futó adatbázisról lehetne beszélni, de teljesen hiteltelenné teszi az írást, hogy egyből az OOP haszontalanságát vezeti le belőle. Egy SQL lekérdezést és egy eredményhalmazt is minden további nélkül lehet objektumorientáltan reprezentálni. Ez az egész nem szól már megint semmiről, csak valami irracionális ellenszenvről.
Ezt a videót már láttam régebben. + Abszolút egyetértek veled és ugyanezt gondolom. Sajnos vannak akik nem képesek felfogni, hogy az eszközeink nem hibásak a mi általunk elkövetett hibákért. Egyébként pedig mindenki azt a módszert használja a saját, céges projektjeiben és egyútal az ügyfelei termékeiben amit akar. Én személy szerint megmaradok az OOP mellett, és a projektekben amiket én irányítok szintén OOP lesz használva, dolgoztam sok-sok évvel ezelőtt OOP és ORM nélkül eleget és még nem halványultak el az emlékeim. :) Aki meg nem akarja ne használja, simán lehet anélkül is dolgozni, csak ne viselkedjenek úgy mintha valaki megakadályozná őket ebben, mintha áldozatai lennének a nagy OOP világösszesküvésnek :D hajrá, hajrá! nem kötelező használni!
Ádám, sosem értettem az ilyen jellegű hozzászólásaidat.
Mindenki a maga tapasztalatai alapján állít bármit is, és az alapján von le következtetéseket. Mivel mindenki mással foglalkozott eddig, ezért ezek rá vagy igazak, vagy pedig nem.
A linkelt Wikipédiás cikk például azt állítja, hogy az ORM miatt sérül az egységbezárás elve. Én ezzel úgy vagyok, hogy szerintem meg nem sérül, vagy legalábbis ez nem olyan nagy gond, és innentől kezdve ezzel nem foglalkozom tovább.
Én legalábbis úgy szoktam olvasni bármit is, hogy ha van legalább egy értelmes gondolat benne, akkor már megérte, a körülötte lévő maszlaggal pedig nem foglalkozom. Szóval engem sosem zavartak emiatt Sting esetleges hülyeségei vagy az Origón lévő elírások, mert mindig az értékes gondolatokat keresem.
A cikk témájához visszatérve, vegyük például a Weblabort! Az eddigi megfigyeléseim alapján (a drupal forrását nem néztem meg) az oldal nagyjából csak egy adatformára, a node-ra épül, gyakorlatilag node-ok láncolata. Egy cikk például egy node, hozzá kapcsolódnak a hozzászólások, amik ugyancsak node-ok, de ugyanígy node-ok a blogmarkok és a munka és állás rovat bejegyzései is. Egy node-nak van egy csomó mezője, és mindegyik bejegyzéstípusnál másra és mára használhatjuk őket.
Ebből következik, hogy a weblabor/drupal lekérdezései végtelenül egyszerűek, nagyjából SELECT * FROM nodes WHERE tipus = 'blogbejegyzes' ORDER BY datum DESC bonyolultságúak. Ebből visszakapunk egy adattömböt n darab mezővel, amiből le kell generálni az egyes szekciók HTML kódját.
Innentől kezdve felmerülhet jópár kérdés: miért kéne ide ORM? Milyen bonyolultságnál érdemes ORM-et használni? Miben segíti a munkát?
Egy weboldal vagy egy webalkalmazás általában az adatbázisnak egy grafikus reprezentációja (view). A megjelenítés nagyjából úgy zajlik, hogy lekérdezzük az adatokat, azokat formázzuk (pl. tizedesvesszőt szúrunk be vagy HTML kódrészletet gyártunk), majd pedig kiküldjük a kliensnek. Az üzleti logika általában az adatok írásánál van (jogosultságkezelés és társaik), megjelenítésnél jóval egyszerűbb az egész. De ha tényleg ennyire egyszerű általában egy weboldal vagy alkalmazás, akkor miért kéne ORM-mel és hasonlókkal bonyolítani a saját helyzetünket?
Számomra legalábbis ez a cikk mondanivalója és kérdése, és emiatt küldtem be.
Én az ORM hasznosságát inkább a forráskód felől közelíteném. Vagyis leválasztja a kódodról az adatbázis menedzselését (ahogy Ádám is írta, azon lehet vitatkozni, hogy ez mennyire igaz), te az adott programozási nyelvben természetes szintaxist és elemeket felhasználva tudsz dolgozni, miközben az objektumokon végzett műveletek eredményeképp az adatstruktúrákat befrissíti az adatbázisból, vagy épp fordítva: kiírja. Pont ezért segíti a munkát: baromi kényelmes tud lenni, hogy hívsz egy user.setName()-et, és az kikerül az adatbázisba. Szintén hasznos, hogy ha olyan nyelvet és editort használsz, sokkal kereshetőbb és jobban láttatja az összefüggéseket, mint az eldugott, beágyazott sql-ekkel. De érteni kell hozzá, és ahhoz is, hogy mi történik a db-ben közben, ezért itt jól be lehet végre böfögni, hogy leaky abstractions :)
Én szeretem is, meg nem is. Előző projectjeimen szerettem és hasznosnak találtam, a mostanin többen nem javasoltuk, de egy részére mégis behúzták. Hát majd meglátjuk. Egy általad vázolt tök egyszerű use case-ben pl pont baromi egyszerűvé teszi a munkát.
A comments külön tábla, és elég érdekes, ahogy egyetlen lekérdezéssel a kívánt, akár fa struktúra szerinti sorrendben adja neked az adatokat.
Szóval annyira nem egyszerű, ugyanakkor - szerintem - erre a Drupal megoldása a legjobb.
Én nagyon sokat tanultam pár éve ennek a Cms-nek az adatbázis kezeléséből.
Az ORM megoldások
Pontosan
https://www.youtube.com/watch?v=BdO4xz64VjQ
BTW, 2008 called, they want their OOP hate back.
Ezt a videót már láttam
ORM
Mindenki a maga tapasztalatai alapján állít bármit is, és az alapján von le következtetéseket. Mivel mindenki mással foglalkozott eddig, ezért ezek rá vagy igazak, vagy pedig nem.
A linkelt Wikipédiás cikk például azt állítja, hogy az ORM miatt sérül az egységbezárás elve. Én ezzel úgy vagyok, hogy szerintem meg nem sérül, vagy legalábbis ez nem olyan nagy gond, és innentől kezdve ezzel nem foglalkozom tovább.
Én legalábbis úgy szoktam olvasni bármit is, hogy ha van legalább egy értelmes gondolat benne, akkor már megérte, a körülötte lévő maszlaggal pedig nem foglalkozom. Szóval engem sosem zavartak emiatt Sting esetleges hülyeségei vagy az Origón lévő elírások, mert mindig az értékes gondolatokat keresem.
A cikk témájához visszatérve, vegyük például a Weblabort! Az eddigi megfigyeléseim alapján (a drupal forrását nem néztem meg) az oldal nagyjából csak egy adatformára, a node-ra épül, gyakorlatilag node-ok láncolata. Egy cikk például egy node, hozzá kapcsolódnak a hozzászólások, amik ugyancsak node-ok, de ugyanígy node-ok a blogmarkok és a munka és állás rovat bejegyzései is. Egy node-nak van egy csomó mezője, és mindegyik bejegyzéstípusnál másra és mára használhatjuk őket.
Ebből következik, hogy a weblabor/drupal lekérdezései végtelenül egyszerűek, nagyjából
SELECT * FROM nodes WHERE tipus = 'blogbejegyzes' ORDER BY datum DESC
bonyolultságúak. Ebből visszakapunk egy adattömböt n darab mezővel, amiből le kell generálni az egyes szekciók HTML kódját.Innentől kezdve felmerülhet jópár kérdés: miért kéne ide ORM? Milyen bonyolultságnál érdemes ORM-et használni? Miben segíti a munkát?
Egy weboldal vagy egy webalkalmazás általában az adatbázisnak egy grafikus reprezentációja (view). A megjelenítés nagyjából úgy zajlik, hogy lekérdezzük az adatokat, azokat formázzuk (pl. tizedesvesszőt szúrunk be vagy HTML kódrészletet gyártunk), majd pedig kiküldjük a kliensnek. Az üzleti logika általában az adatok írásánál van (jogosultságkezelés és társaik), megjelenítésnél jóval egyszerűbb az egész. De ha tényleg ennyire egyszerű általában egy weboldal vagy alkalmazás, akkor miért kéne ORM-mel és hasonlókkal bonyolítani a saját helyzetünket?
Számomra legalábbis ez a cikk mondanivalója és kérdése, és emiatt küldtem be.
Én az ORM hasznosságát inkább
Én szeretem is, meg nem is. Előző projectjeimen szerettem és hasznosnak találtam, a mostanin többen nem javasoltuk, de egy részére mégis behúzták. Hát majd meglátjuk. Egy általad vázolt tök egyszerű use case-ben pl pont baromi egyszerűvé teszi a munkát.
Kicsit több
Szóval annyira nem egyszerű, ugyanakkor - szerintem - erre a Drupal megoldása a legjobb.
Én nagyon sokat tanultam pár éve ennek a Cms-nek az adatbázis kezeléséből.