ORM z druhé strany
Školení, která pořádám 
Martin Malý píše o tom, co mu vadí na ORM (především nutnost synchronizace mezi kódem a databází) a nepřesně mě zmiňuje:
Chvíli jsem přemýšlel o řešení Jakuba Vrány, který si, jestli se dobře pamatuju, parsuje SQL a z něj si generuje strukturu pro třídu, ale furt se mi to zdálo příliš složité.
Já se ve svých myšlenkách (žádné ORM jsem nenapsal ani nepíšu) ubírám jiným směrem. Jde o to, že v kódu vůbec žádný seznam polí v jednotlivých tabulkách být nemusí. K čemu by mi tam vlastně měl být?
- Když uvedu neexistující název sloupce, tak se o tom dozvím v momentě, kdy se do databáze posílá sestavený dotaz nebo když se přistupuje k neexistující vlastnosti. To je sice o maličko později než když bych měl seznam sloupců k dispozici, ale je to ve stejné fázi (konkrétně při spuštění kódu, protože při kompilaci PHP přístup k neexistujícím vlastnostem nijak neověřuje).
- Datové typy mě prakticky nemusí zajímat, data mohu ošetřovat podle jejich PHP typu. Když třeba přešvihnu délku řetězce nebo pošlu NULL do NOT NULL sloupce, tak se o tom opět dozvím chybou nebo varováním databáze.
- Hlavním motivem tak může být to, aby IDE napovídalo názvy sloupců při práci s objektem. To ale řešíme problém IDE a nikoliv kódu, takže bych to raději řešil na úrovni IDE. Jistě by šel alespoň do některých IDE dopsat plugin, který by třeba při anotaci
@tabledokázal seznam vlastností načíst ze struktury tabulky.
Stručně řečeno: Bez seznamu sloupců v kódu se dá bez problémů obejít, takže synchronizaci mezi kódem a databází nemusíme vůbec řešit. Když bych informace o sloupcích mermomocí chtěl (třeba kvůli včasnější kontrole), tak bych je spíše získával reflexí (SHOW COLUMNS) při spuštění.
Diskuse
Tom:
a "diky" zakazanym komentarum na misantropovi se musi reakce, ktere by se hodily do diskuze k clanku, trousit po X dalsich blozich :(
Jakub Vrána 
:
Taky mi to přišlo trochu líto. Na druhou stranu v začátcích blogování to bylo úplně normální. Navíc napsání příspěvku na blog chce trochu víc pečlivosti než napsání komentáře, takže myšlenka pak není tak zkratkovitá.
Jakub Vrána : Martin Malý:
Přesně tak. Vidíte, oč je takováhle reakce přínosnější, ucelenější a smysluplnější (navíc na dobrém místě), než utopený výkřik někde v haldě komentářů?Tomáš Kafka:
Nestálo by teď za to doplnit pro čtenáře kteří sledují jen jednoho z vás chybějící článek - odkaz z misantropa na vybrané relevantní články jinde? Takové manuální trackbacky :)Martin Malý:
K článku se nehodí žádný komentář. Děkuji za pochopení.já:
Synchronizace mezi kódem a databází není přece třeba řešit u ORMu nikdy. Buď se kód sám "upravuje" podle databáze nebo tradičněji databáze "sama" podle návrhu kódu (Propel, Doctrine).
Petr Kozelek:
Doporučuju prostudovat si projekty jako Hibernate v Javě a jeho klon NHibernate v .Net, které problematiku ORM řeší velmi komplexně. Navíc už jsou docela staré a mají početnou komunitu, takže už si dávno prošly porodními bolestmi začínajících frameworků.
Petr Kozelek: Martin Malý:
Já vím že to není přesné. Já si vzpomněl na tvůj nástroj pro generování adminských rozhraní, cos předváděl na té konferenci s Vilémem Málkem (zapomínám jak se jmenovala). A vybavilo se mi, jak sis lehce rozšířil SQL a uložil si nějaké informace o vazbách do SQL komentářů, a z toho jsi pak generoval to adminské rozhraní. Pokud jsi to během těch let změnil, tak se omlouvám.Diskuse je zrušena z důvodu spamu.
© 2005-2024 