OT: Více vrstev modelu, efektivita

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
Fanda
Člen | 39
+
0
-

Čím víc přemýšlím o vrstvách v modelu, tím víc mi dává smysl používat Nette database selector/notorm na co nejvyšší úrovni, ne-li v prezentéru, nebo použít něco jako doctrine. Repository a mappery donutit pracovat efektivně směrem k databázi/paměti je docela záhul. Máte na to někdo jiný názor? Máte někde kód, kde je vidět nějaké vícevrstvé a přitom efektivní řešení?

Kde vidím hlavní vady na kráse (může vyplývat z neznalosti):

  • v repository načtu články a v případě kompozitních objektů bych měl načíst i autory, i přesto, že je později nevyužiju (jedním dotazem bych si přitom mohl vytáhnout jen to, co využiju)
  • pokud je model objektový, pro jeden sloupec tahám všechna data
  • pokud repository nechám pracovat výhradně s objekty, abych mohl smazat objekt, jehož znám id, měl bych sestavit objekt (načíst z db) a následně smazat. Totéž by bylo s editací.
  • určitě budou i další, které teď nemám v hlavě

Jak řešíte tyhle otázky? A pokud bych se chtěl vyhnout doctrine? :-) I když jsem docela perfekcionista, přestávám zatracovat zatracovaný příklad Davida s využitím selectoru v šabloně… :-)

Díky za názory.

Nox
Člen | 378
+
0
-

Souhlasím, no z principu na efektivitu zaměřený kód asi bude rychlejší, ale méně čistý než ten zaměřený na čistotu…

  1. Řeším osobně tak, že pokud předem vím co chci, tak pomocí doplňujících metod načtu co bude třeba

Pokud nepoužíváš result cache (afaik D2.2+), tak pak je míň efektivní cachování (jako třeba to v šabloně), pro to se víc hodí lazy loading. Tudíž balancovat, to co prostě vím že je (skoro) vždy třeba – načtu hned. To co je potřeba na dané stránce a vím to předem taky načtu hned. Zbytek nechám lazy a kdyžtak cachnu

  1. Pravda pravda… jsou sice partial objekty, ale s těma se moc nedoporučuje.

Bylo by zajímavý, kdyby tam bylo něco jako má NotORM…

  1. Tady bych prostě šel cestou povolit jak ID, tak objekt… D2 umí mazat objekty pomocí DQL čistě jen přes ID

To neznamená, že se musíš vzdát kontroly typu, prostě se dá instanceof. S ID je to těžší, protože ID může být taky objekt, nebo číslo, nebo řetězec atd. … šlo by to udělat přes nějaké tahání definice – kód zaměřený na čistotu by to tak asi udělal. Tuším ale, že by to nebylo zrovna nejrychlejší, ale nevim teď jak bych to dělal

  1. a tak vůbec

J, přiznávám, že výkon je věc co mě na Doctrine celkem trápí, jinak teda jsem fanda…
Ale spíš z hlediska CPU … přijde mi, že D2 je mnohem náročnější na CPU/paměť než na DB

Edit: teda doufal jsem, že tu přispěje víc lidí :)

Editoval Nox (8. 12. 2011 9:16)

Ani
Člen | 226
+
0
-

Máme vlastní vrstvu bohužel nepublikovatelnou (ani ne tak že by jsme to tajili, ale pro neznalého to je strašně zmatené, nepublikovatelné, neboť je to stále ve vývoji).

  1. Používáme řešení které umožňuje definovat co chci předem, případně to má i možnost lazyloadingu (u kolekcí ve stylu notorm).
  2. Tohle zatím neřešíme, ikdyž máme možnost si jednotlivé property načítat také lazy (zatím používáme u věcí které se musí třeba složitě počítat a používají se málo, nějaké relevance profilů a tak).
  3. V tom nevidím problém, je to prostě jen jeden dotaz navíc a ty opereca se často nedějí. Navíc když objekt mažu/edituju, tak si ho stejně většinou potřebuju načíst pro nějaký výpis, kontrolu oprávnění…

Všeobecně si myslim že kombinace lazyloadingu s možností setsavit si dotaz předem je docela efektivní a člověk má ty objekty konzistentní. Nadruhou stranu je s tím hodně psaní, zvlášť když se použije třeba virtualproxy pro ten lazyload. Samotná implementace toho řešení je celkem v pohodě, ale pak těch objektů, proxy tříd, interface pro ten objekt a proxy, repozitářů… V tom je lepší doctrine s tím jak sy vytváří třídy.

V podstatě doctrine se mi zdá ideální při použití dql jen škoda že neumí načítání u kolekcí jako notorm, v tom vidim největší výkonostní problém.

Editoval Ani (8. 12. 2011 23:09)

Patrik Votoček
Člen | 2221
+
0
-

Každá abstrakce ti vždy bude žrát nějaký ten výkon. Nicméně u Doctrine je to tak trochu vykoupeno díky IdentityMap a možnosti práce s klasickýmy objekty.

Ad načtění objektu při mazání. Nevím jak ty ale já ve 100% případů potřebuju i ten objekt. Nejčastěji proto abych si vytáhnul jeho jméno, které pak použiju ve flash zprávičce.

Btw nic ti nebrání mazat DQLkem bez nutnosti tahat/mapovat objekt. :-)

Fanda
Člen | 39
+
0
-

Ani napsal(a):

  1. K tomuhle řešení postupně taky docházím. Že bych před dotazem repository řekl, co všechno související chci dostat ve výsledku. V souvislosti s nette database selectorem mě ještě napadlo, aby byly zachovány zodpovědnosti, do jednotlivých repository udělat (nesystémovou) metodu pro příjem nette database selection, aby vše fungovalo hezky kaskádově jak je to navrženo (třeba se pletu, ještě jsem to nezkoušel). A kolekcím dát metody pro případné donačtení dat.
  2. Asi je užitečnější tohle neřešit. :-)
  3. S tím mazáním máte asi pravdu

Do doctrine se mi pořád nějak moc nechce (i když na ní mám jeden projekt rozdělanej). Na ty menší věci bych rád něco elegantního lehkýho. :-)
Díky Vám za názory.