Migracia na Doctrine, alebo iny ORM
- fizzy
- Backer | 49
Uvazujeme o prechode jedneho stredne velkeho projektu (eshop) na Doctrine alebo iny ORM. Mate skusenosti s prechodom? Ako najlepsie postupovat?
System momentalne vyuziva Nette\Database, databaza ma okolo 150 tabuliek. Ku kazdej z nich je vytvorena nejaka „Repository“ trieda s operaciami nad tabulkou. Tento sposob uz nie je velmi vyhovujuci, system sa nam velmi rychlo rozrastol a dalej rastie.
Jedine riesenie co ma napadlo je pouzivat sucasne Nette\Database s ORM a postupne prerobit vsetky casti systemu na ORM.
Dakujem za akekolvek rady :)
- newPOPE
- Člen | 648
Domnievam sa, ze na toto nie je jednoznacna odpoved. Skor by som pracoval s tym co mate a navrhol si nejaky postup refaktoru smerom k stylu Doctrine.
nieco na zamyslenie:
- preco Nam to nevyhovuje? Neda sa to prerobit tak aby to vyhovovalo (refaktor, vyhadzovanie tabuliek, rozbitie na event based system, mozno modules/microservices, …)
- naozaj nas Doctrine zachrani? Co z nej realne vieme vyuzit hned a co bude treba upravovat
- kolko casu ⇒ penazi nas bude stat spravovat aj NBD aj ORM. Budeme stihat pokryvat aj vyvoj novych poziadaviek?
Editoval newPOPE (8. 7. 2015 10:55)
- fizzy
- Backer | 49
Postupne robim refaktoring celeho systemu, spominany event system je tiez v plane. Co nevyhovuje je mnozstvo servisnych tried ktore maju bezne aj 30 zavislosti, vacsina logiky je riesena prave v tychto service triedach a to by som chcel presunut niekde na nizsiu uroven.
Kolko casu/penazi to neriesim, je to vlastny projekt, praca aj hobby, refaktoring robim vo volnom case ked nie su nove poziadavky.
- hrach
- Člen | 1844
Migrujeme jeden velky projekt (signaly.cz) na Nextras\ORM. Projekt byl napsan s pomoci vlastni db vrstvy nad dibi. Poznamky k migraci:
- prepisujeme to po castech, vzdy jeden velky balik se udela najednou (napr. blogy).
- aktualne mame dve casti, blogy, fotky, pripravuji se akce, nicmene hodne entit z ostatnich casti systemu je uz vytvorenych, tj. prepisovani se stava pomalu jednodussim, protoze nektere podpurne veci uz jsou hotove a vyresene.
- mnoho kodu se maze, protoze uz neni treba, ORM to dela za nas, hlavne ruzne dotazy na zefektivneni nacitani, protoze to ORM resi za nas, vetsina dotazu se napise fluentem velmi rychle, ukladani relaci etc. je tez v ORM.
- samozrejme prepisovani db vrstvy nese i znacne dodatecne naklady, protoze logicky je treba upravovat kod s tim souvisejici, respektive kod stary 5 let.
- impulsem bylo zejmena to, ze migrace na postgre nebyla prakticky mozna, mnoho sql dotazu a to jeste „skladanych“, ze rozumne to upravit by znamenalo to cele prepsat, takze to cele prepisujem, ale do jineho nastroje.
- Filip Procházka
- Moderator | 4668
Damejidlo jsme migrovali přesně jak popisuje @hrach. Postupně, od nejmenších subsistémů ke větším. Přepsat celou aplikaci najednou je nereálné a zabije projekt.
Kdyby/Doctrine obsahuje bridge, kterým si můžeš napojit dibi na connection z doctrine a tedy se pak nepřipojuješ k databázi 2×. Určitě bude velice jednoduché napsat podobný pro NDB.