Proč ORM? rubrika: Folklór

12 Kit
položil/-a 11.7.2015

Před týdnem jsem tuto otázku položil Googlu. Většina odkazovaných odpovědí byla ve stylu "Proč nepoužívat ORM". Zajímal by mě však důvod, proč někteří vývojáři ORM používají a také které používají.

Zatím jsem žádné ORM nepoužil, protože jsem k tomu ten důvod nenašel. Servisní vrstvu mezi modelem a databází mívám rozdělenu do množiny poměrně tenkých domén a SQL dotazy si do nich píši přímo. Nenapadá mě zda a jak by se to ještě dalo zefektivnit.

Nepoužívá se ORM jen proto, že vývojáři neumí pracovat s relačními databázemi?

Komentáře

  • Honza Břešťan : "Nepouziva se managed jazyk jen proto, ze vyvojari neumi pracovat s pointery?" — 11.7.2015
  • Kit : Jakou to má souvislost? — 11.7.2015
  • Stefano : @kit - Odkaz na tu otazku na googlu?? — 11.7.2015
  • Anonym : @Kit Používáš v jednom projektu několik různých DB? — 11.7.2015
  • Kit : @dq3zuSNbre: Jak kdy. Obvykle jednu, ale už jsem měl i čtyři DB různého typu. Také provozuji jednu aplikaci na více serverech a na každém je trochu jiná struktura DB. — 11.7.2015
  • arron : @Kit: Mno tak jak jsem to pochopil s těch diskuzí tady, tak vlastně používáš ORM :-) Jenom tomu tak možná neříkáš :-) — 14.7.2015
  • Kit : @arron: Vypadá to tak. Jenže to mé "ORM" je tak jednoduché, že se tomu bojím tak říkat. Je to skutečně jen pár desítek řádek pro každou doménu a SQL (+ NoSQL) uvnitř těch domén píši ručně. — 14.7.2015
odkaz
9 Augi
odpověděl/-a 12.7.2015
 
upravil/-a 12.7.2015

Určitě by tu měl být odkaz na sice starší, ale stále aktuální, článek Martina Fowlera.

Problémem ORM knihoven je IMHO to, že se snaží být příliš chytré. Ono jim ale nic jiného nezbývá, protože ORM je těžký problém. Pak je ale otázka, jestli si chceme vnášet do projektu těžký problém, který nepřináší žádnou business value.

Ve světě frontendu nedávno přišli na to, že two-way-databinding (ne, nenapíšu jméno toho hnusu) je zbytečně těžký problém a je lepší se podívat na celý problém trošku z dálky a přehodnotit, jak psát aplikace. A tak vznikl Flux. Což není nic jiného než CQRS, který se používá na backendech léta (i MVC jsem doiteroval do stavu, kdy jsem měl ReadModel a WriteModel).

Jak ale píše Martin Fowler ve svém článku - to, že nějaký nástroj vyřeší jen 80 % problémů neznamená, že je úplně k ničemu a měli bychom ho zavrhnout. Takže pokud by mi ORM usnadnil významně práci, klidně bych ho použil.
U sebe to ale vnímám tak, že od ORM potřebuju jen tupé mapování z nějakého readeru na immutabilní doménové objekty nebo read-modely. A tuto práci velmi dobře (a levněji) zastanou micro ORM frameworky.

Takže odpověď na otázku: Pokud píšeš aplikace takovým způsobem, že ti ORM nic nepřináší, nebo dokonce hází klacky pod novy, tak ho opravdu nemá smysl používat. Ruční psaní mapování mezi nějakýma readerama a objektama může být někdy pruda a tam se může vyplatit poohlédnout po nějakém micro ORM. Hodně micro ORM jsou jen jeden soubor, takže pokud ti API žádného micro ORM nevyhovuje, není žádná ostuda napsat si vlastní, který perfektně sedne tvému projektu/styl psaní aplikací.

Komentáře

  • Kit : Zmíněný článek od Martina Fowlera znám, ale i tak díky za rozšíření pohledu na problematiku. Používám ruční mapování organizované do domén. Při vytváření nových domén využívám recyklace stávajících - možná zde je prostor pro použití dědičnosti a vyextrahování společných prvků do rodiče. Zatím jsem k tomu však nebyl motivován, protože i domény obsahující kompletní CRUD bývají kratší než mých limitních 65 řádek. — 12.7.2015
  • rmaslo : Hezky napsaný. A za mě naprostý souhlas. Pro doplnění jsem chtěl jsem přidat článek který mě kdysi dávno fakt hodně ovlivnil. Když jsem ho vygooglil tak jsem zjistil žes ho napsal ty :-) http://www.augi.cz/programovani/architektura-skalovatelnych-aplikaci/ — 13.7.2015
  • rmaslo : Jinak ReadModel je pro mě nyní rozhraní SQL tj. ptám se pomocí SQL SELECTů Tyto SELECTy si mohou volat nějaké PHP procedury - typicky plnění dočasných tabulek. V přístupu k WriteModelu používám tři procedury Update, Insert, Delete v nichž mohou být pro jednotlivé "zdroje" (tabulky či virtuální tabulky) volány "datové události" After a Before tj. přenesl jsem koncepci trigerů z SQL do PHP. S Write částí jsem naprosto spokojen. ReadModel má drobnou chybičku - tyto dotazy lze zadávat jen ze serveru, protože v jejich zpracování již není kontrola na "neakčnost dotazu". Proto si (abych je mohl zadávat i z klienta) píšu knihovnu která je bude tvořit z nějaké JSON struktury. Takový jakoby posun k LINQ. — 13.7.2015
  • Kit : ReadModel a WriteModel mám sloučeny do jedné domény. V každé doméně mám tedy metody create(), find(), select(), insert(), update() a delete(). — 13.7.2015
  • rmaslo : @Kit: Doménou předpokládám myslíš "úložiště jednoho typu dat", nikoliv doménu ve smyslu doménové logiky celé aplikace? PS: Jaký je rozdíl mezi create a insert ? A mezi find a select? — 13.7.2015
  • Kit : @rmaslo: Myslím tím doménu ve smyslu doménové logiky aplikace. Může tedy poskytovat data z více zdrojů jako jeden balík, který je požadován. create() vytváří struktury (metadata), insert() vkládá data, find vyhledá jednu (první) relaci - "fetch()", select poskytne množinu relací - "fetchAll()". Pro komunikaci s doménou většinou používám messengery s opožděnou validací v doméně. — 13.7.2015
  • rmaslo : @Kit: jj rozumím a v principu souhlas. Já osoobně create zrušil - Metadata považuji také za data a spravuju je pomocí insert, update, delete. Vysvětlím na paraele s SQL enginem - asi takto: Představ si, že v SQL zrušíš vnější volání CREATE, DROP, ALTER atd... Information_schema necháš veřejné a povolíš do něj write. Nad jednotlivými tabulkami information_schema si pak uděláš trigery, který Ti volají ty vnitřní příkazy. Takže z vnějšího API zavoláš něco jako DELETE FROM tables WHERE table = "myTable". No a triger nad tables zavolá opravdové DROP TABLE myTable. Takto tedy spravuji metadata modelu - mám v nějakých speciálních tabulkách a spravuji je jako jakáliv jiná data. — 13.7.2015
  • rmaslo : @Kit: Ještě dotaz k tomu find() a select(). Co je jejich vstupem? Nějaká struktura z které vytvoříš v modelu SQL SELECT? A jaké jsou možnosti této struktury? — 13.7.2015
  • Kit : @rmaslo: To s tím zrušením create a náhrada doménou nad metadaty vypadá jako skvělý nápad. Zkusím si to promyslet. Metody find() a select() jsou metodami modelu a mají jako parametr tu doménu. Ta doména obdrží strukturovaná vstupní data v konstruktoru. Volání pak vypadá asi takto: $user = $model->find(new User(array('id' => $userID))); Model pak přes DI zavolá tu doménu a předá jí databázi, ve které má hledat. — 13.7.2015
  • rmaslo : Ano je to doména nad metadaty - správně jsi pojmenoval. Na té Read straně (find) se já kloním spíše k dotazovacímu jazyku, tj. něco jako SQL předpřipravené v JSONu, který si model složí. Ale to je dané tím mým "nevyužitím ORM". A chápu tvůj přístup pokud chceš mít API modelu "objektové". — 13.7.2015
  • Kit : @rmaslo: Nelíbilo se mi, jak se model neustále zvětšoval a s tím se i komplikovaly názvy metod. A protože je mám rád jednoslovní (jedno sloveso), vymyslel jsem tohle. Model se smrskl na pár desítek řádek a vlastně jen nese informace o připojených datových zdrojích, které injektuje do zmíněných domén. Kromě toho slouží jako proxy přístupových metod. To velmi usnadňuje testování, protože místo datového zdroje mohu doméně předhodit mock nebo jinou databázi prostřednictvím mockovaného modelu. — 13.7.2015
  • rmaslo : @Kit: jj v pohodě. Abych řekl pravdu mě se to na to, že to je ORM docela líbí :-). Jednoslovnost souhlas. — 14.7.2015
  • jan.flos : Tohle jsem nepochopil a prosím o vysvětlení : "Ve světě frontendu nedávno přišli na to, že two-way-databinding (ne, nenapíšu jméno toho hnusu)" je zbytečně těžký problém a) Jak lze tento výrok chápat z hlediska MVVM paradigmatu, který je založený na two-way databindingu ? b) Nevztahuje se tento výrok pouze na webové aplikace ? — 17.7.2015
  • vojta.tranta : Osobně si to bez něčeho, co mi dělá nějakou abstrakci nad sql nedovedu představit, tsejně tak bez automatické tvorby migrací. Ale nejsem tak skilled, abych do toho vyloženě kecal. — 25.9.2015
  • vojta.tranta : Třeba ORM v Djangu je naprosto super, žádný otravný doktrína, ale to je možná jazykem. — 25.9.2015
  • Kit : @vojta.tranta: Je to hodně o zvyku. Běžně mívám MySQL otevřené v konzoli a volně preluduji - vytvářím si tabulky, vazby, pohrávám si s daty. Odezva toho, co je dobře či špatně, je okamžitá. Proto mi vůbec nedělá potíže pracovat s jazykem SQL ani uvnitř jiných jazyků. — 26.9.2015

Pro zobrazení všech 18 odpovědí se prosím přihlaste:

Rychlé přihlášení přes sociální sítě:

Nebo se přihlaste jménem a heslem:

Zadejte prosím svou e-mailovou adresu.
Zadejte své heslo.

Aktuální otázky v rubrice Folklór

Otázky uživatele Kit