Object Relational Mapper - ORM

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Da li neko može ovo detaljnije da razloži, predloži neki tutorijal i da objasni namenu i svrhu a ono što me najviše zanima jeste sigurnost.
Hvala!

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Uf ovo je moj sektor. Neznam sta te konkretno zanima ? Ako oces profi ORM onda Doctrine.

Doctrine je nesto najbolje sto je ikada napravljeno do sada bar za mene, ja bez njega neidem nigde. Neko vise voli Propel mada sam ja ipak vise za doctrine.

Sama rec ti kaze => Objektno orjentisano mapiranje

Jednom recju sve je objekat. Pazi primer kod doctrine

Imas tabelu products.

Doktor sam generise strukturu tabele pomocu enititeta i anotacije.

Prvo kreiras entitet da bi doktor znao strukturu tabele, jer to je i pojenta. Entitet ti je ono O u ORM. Sve je objekat.
// src/Acme/StoreBundle/Entity/Product.php namespace Acme\StoreBundle\Entity; use Doctrine\ORM\Mapping as ORM; /**  * @ORM\Entity  * @ORM\Table(name="product")  */ class Product {     /**      * @ORM\Column(type="integer")      * @ORM\Id      * @ORM\GeneratedValue(strategy="AUTO")      */     protected $id;     /**      * @ORM\Column(type="string", length=100)      */     protected $name;     /**      * @ORM\Column(type="decimal", scale=2)      */     protected $price;     /**      * @ORM\Column(type="text")      */     protected $description; }

Anotacije :

@ORM\Table(name="product") = govori doktoru kako se zove tabela koju ce generisati
@ORM\Column(type="integer") = kojieg je tipa polje
@ORM\GeneratedValue(strategy="AUTO") = sql auto increment
@ORM\Column(type="string", length=100) = tip polja je string duzine 100

protected $id; = svaki property je jedna kolona

Kada je entited generisan ti onda svojoj bazi pristupas putem objekata datog entiteta, sto ja mocna stvar. Mozes zaboraviti one iskaze i ostala cudesa koja su otezavala posao...

Npr:

public function createAction() {     $product = new Product();     $product->setName('A Foo Bar');     $product->setPrice('19.99');     $product->setDescription('Lorem ipsum dolor');     $em = $this->getDoctrine()->getManager();     $em->persist($product);     $em->flush();     return new Response('Created product id '.$product->getId()); }

Znaci nikad lakse i nikad cistiji kod. Sad si upisao novi proizvod u bazu i vratio si response da je proizvod sa tim ID-om kreiran

Gore nisam napisao u klasi geter i seter metode koje us potrebne to mezes i sam.

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Kao što _iKaC_ kaže, divna stvar i ubrzava bootstraping višestruko. Ipak, imaj u vidu da, i recimo Doctrine koji je "najmasovniji" u PHP svetu (Symfony i Zend ga koriste "po defaultu") ima svoje boljke. Na primer:

1. Potreba da se nauči DQL (doctrine query language) i njegovi nedostaci
Iako ćeš jako često koristiti već gotovu apstrakciju koju ti pruža sam Doctrine, u bilo kojem iole ozbiljnijem projektu moraćeš da praviš svoje upite kojima ćeš sprečiti da dođe do "lazy loadinga". Za to ćeš koristiti DQL. U principu, oni ti dozvoljavaju da koristiš i SQL ali je na tebi da pomoću resultset mappera izmapiraš taj rezultat upita nazad na modele (ili kako ih Doctrine zove Entitete).

Drugo, probaj da napraviš kroz DQL selekt INVERZNE strane veze, završićeš sa upitom kao što je ovaj zbog ograničenja samog DQL-a:

SELECT     p FROM     SitePage p JOIN     SiteVersion v WITH     1 = 1 JOIN     v.pages p2 WHERE     p.id = p2.id     AND     v.id = :versionId     AND     p2.slug = :slug

2. Migracije
Iako ti ORM pruža mapiranje baze direktno na objekte, pitanje je kako ćeš u postojećem projektu koji je već u produkciji izvršiti neki ozbiljniji refactoring koji uključuje izmenu relacija i ostalog. Doctrine ORM nudi integraciju sa Doctrine DataMigrations bibliotekom, ali ona je svedena na to da on može da pretpostavi šta ti želiš da uradiš, što će retko biti zaista to što želiš pri bilo čemu iole kompleksnijem.

Ima tu i "problema" sa performansama, ali je ovo jako opipljivo. U principu, ja mislim da je prednost koju ti daje doctrine da manje razmišljaš o samoj bazi isplativa jer gubici na performansama najčešće nisu znatni i osim u nekim ekstra-ozbiljnim slučajevima mislim da je sasvim ok i neosetna razlika. Takođe ti daje gotovu apstrakciju oko baze sa Doctrine DBAL-om koja je spremna za implementaciju keširanja tako da će na kraju biti brža od nekog prosečno napravljenog custom data-persistence sistema.

Sve u svemu, ja ti toplo preporučujem da probaš ukoliko nisi!

• 0Niko još nije pohvalio poruku.
  Registruj se da bi pohvalio/la poruku!

Ovo je zanimljivo, probaću. Do sada sam sa bazom upravljao preko jedne klase u kojoj imam funkcije za listanje, snimanje, brisanje, kopiranje, pretragu... Sve sam stavio u OOP i tako vadim po potrebi. A koristim jednu klasu koja mi mapira sve tabele i polja u bazi. Ako tabela ne postoji po default, onda je napravi i to je to posle. To radim preko admina i prepišem unutar PHP-a fajl gde se nalazi nova klasa. Ali baš me i ovo zanima...