Statická proměnná v DI, opravdu zlo?

Zkus spustit tento kód

class Foo {

	public function __construct(
		private int $value,
	)
	{
	}

	public function getList(): int
	{
		static $cache;

		if ($cache) {
			return $cache;
		}

		return $cache = $this->value;
	}

}

$first = new Foo(1);
$second = new Foo(2);

var_dump($first->getList());
var_dump($second->getList());

Výsledek bude:

int(1)
int(1)

PS: Tohle asi není odpověď úplná odpověď na tvoji otázku, ale tady je jen příklad proč jsou static dobrý sluha, ale zlý pán.

Editoval Martk (30. 3. 2023 23:03)

a čo tak nešpekulovať a proste to napísať takto?

class Foo {
	private ?array $cache = null;

	public function getList(): array
	{
		if ($this->cache === null) {
			return $this->cache;
		}

		return $this->cache = $this->table('xx')->where(..)->fetch()->toArray();
	}
}

používam úplne bežne…

EDIT: opravené if ($this->cache) – diky @h4kuna

Editoval MajklNajt (31. 3. 2023 13:18)

Problem je ze to spoleha na to ze vzdy a vsude bude prave jen ta jedna instance. Coz je mozna pravda ted, ale nemusi byt pravda az ten kod za rok nekdo upravi podle novych pozadavku.

1. Cachovat v instancni a ne staticke property.
2. Injectnout si cache jako zavislost (pak se lip pracuje s invalidaci)

Ten kdo s tim kodem bude pracovat nemusi cist kod celyho projektu, aby tyhle chytaky objevil a vedel ze si na ne ma dat pozor.

A proč tu funkci vůbec voláš se stejnými parametry víckrát na jedné stránce – k čemu to potřebuješ? Nedává smysl ten výsledek spíš předat nějak v presenteru nebo kde to používáš? Pak bys žádnou cache ani nepotřeboval.

Editoval dakur (31. 3. 2023 12:12)

dakur napsal(a):

A proč tu funkci vůbec voláš se stejnými parametry víckrát na jedné stránce – k čemu to potřebuješ? Nedává smysl ten výsledek spíš předat nějak v presenteru nebo kde to používáš? Pak bys žádnou cache ani nepotřeboval.

Mám třeba následující model.

<?php
	public function getList(): array
	{
		$this->getBase();
		return $this->list;
	}


	public function getFullList(): array
	{
		$this->getBase();
		return $this->fullList;
	}

A metoda getBase je práve zakešovaná a ukládá do členských properties (list / fullList .. je jich víc) data a já na to mám pak gettery, a různě je volám .. přijde mi to OK.

?>

Kdyz pouzivas nejakou tridu nemelo by byt nutne si nejdriv prostudovat cely jeji kod.

Je spousta moznosti jak ti statika muze zpusobit problemy.

Napr. Co kdyz jian trida zmeni data ktera mas nacachovana v te staticke cachi? Najednou se system zkatujr chybna data a nevis proc dokud nanajdes nekde schovanou tuhle cache.

Je to sice jednodussi zapis ale za cenu toho ze je mnohem slozitejsi si udrzet prehled kde vsude se neco takoveho deje a dat si na to pozor.

Udrzovat takovy kod je pak mnohem slozitejsi.

Jedine misto kde to je imho ok je cache vysledku pure metod – tedy tam kde vysledek zavisi jen a pouze na hodnotach parametru a nicem externim.

Ty nwvyhody nejvic vyniknou v okamziku kdy zacnes pro ten kod psat automaticke testy. Zjistis ze nektere veci zacnou byt neresitelne.

@Klobás

Jen se snažím pochopit viz ten začátek, proč je statická proměnná zlo :-), přijde mi totiž, že v tomto případe je to v pořádku.

Takhle teoreticky s vymýcením statických proměnných nelze než souhlasit. Máš ale pravdu, že je potřeba jednoduše vyřešit problém duplicity sql dotazů, protože to se stává dost často, že jedny data (typicky ActiveRow, ale i Selection) se v rámci jednoho presenteru využívají na více místech.

Jak průběžně vidím na fóru, řeší to lidi různými způsoby a žádné nejlepší řešení není nejlepší.

Ty Jsi to vyřešil cachováním sql dotazu rovnou v metodě modelu a to v rámci jednoho requestu, kde jak píšeš není žádná invalidace cache nutná. S tím já souhlasím, pokud je presenter jednoduchý tak problém nebude. Při dalším rozvoji presenteru ale k chybě dojít může díky tomu, že cachování je schované (popisuje @mystik).

Cachování můžeš zachovat, ale do property presenteru:

class ArticlePresenter extends BasePresenter
{
   private Selection $articles;

   public function __construct(
      private ArticleModel $articleModel,
      private ArticleMenuFactory $articleMenuFactory,
   )

   public function actionList()
   {
      $this->articles = $this->articleModel->getList();
      ... // první použití dat
   }

   public function renderList()
   {
      $this->template->articles = $this->articles; // druhé použití dat
   }

   public function createComponentArticleMenu(): ArticleMenu
   {
      $this->articleMenuFactory->create(articles: $this->articles); // třetí použití dat
   }
}

Data se cachují, ale přehledným způsobem.

Bohužel nám toto nabourává jiný doporučovaný návrhový vzor a sice delegování práce presenteru do komponent, kdy factory dodá komponentě služby které potřebuje nezávisle na presenteru. Takhle jak jsem to napsal totiž data komponentě dodává presenter.

Bohužel pro často se vyskytující případy kdy více komponent využívá stejná data ideální řešení neexistuje:

a) data dodáme opakovaně z modelu – sql bude duplicitní
b) zacachujeme data v modelu – nepřehledné
c) data cachujeme v property presenteru – komponenta nebude nezávislá

I když nejde splnit všechny dobře míněné návrhové vzory současně, protože se vlastně navzájem vylučují, tak třeba řešení c) vůbec špatné není a pokud se komponenta přesune do traity tak skoro ideální.

@mystik

Za me idealni cachovat v modelu.

A používáš jakou databázovou knihovnu? Nette\Database\Explorer nebo nějaký ORM?

Mohu požádat o kousek kódu na ukázku jak takový cachovaný model vypadá? Ideálně ve variantě pro Nette\Database\Explorer, ale nevadí i ve verzi ORM.

@mystik

Mam vlastni „ORM“ nad Nette\Database\Explorer. Nejsem ted u PC, ale neni tam noc sloziteho.

Joo, to by mě zajímalo, kdyby Jsi si na mě náhodou někdy vzpomněl, něco takového bych si rád prohlédl, abych nemusel vynalézat kolo ;)

Obvykle resim jen sem tam pro veci jako ciselniky.

To znamená, že to cachuje dlouhodobě v přesahu přes několik requestů, třeba i řádově měsíce – do další změny v číselníku?

Btw v tomto vlákně se řeší duplicita sql v rámci jednoho requestu. Napadá mě, že když proběhnou dva/tři duplicitní sql dotazy v jednom presenteru bleskově za sebou v rámci jednoho připojení, tak databáze do hloubky neznám, ale tipoval bych, že toto bude nějakým způsobem v databázovém serveru cachováno a zátěž vzniklá duplicitními dotazy bude minimální. Takže v nízkozátěžové aplikaci by se duplicity sql možná nemusely řešit.

m.brecher napsal(a):

@Klobás

Jen se snažím pochopit viz ten začátek, proč je statická proměnná zlo :-), přijde mi totiž, že v tomto případe je to v pořádku.

Takhle teoreticky s vymýcením statických proměnných nelze než souhlasit. Máš ale pravdu, že je potřeba jednoduše vyřešit problém duplicity sql dotazů, protože to se stává dost často, že jedny data (typicky ActiveRow, ale i Selection) se v rámci jednoho presenteru využívají na více místech.

Jak průběžně vidím na fóru, řeší to lidi různými způsoby a žádné nejlepší řešení není nejlepší.

Ty Jsi to vyřešil cachováním sql dotazu rovnou v metodě modelu a to v rámci jednoho requestu, kde jak píšeš není žádná invalidace cache nutná. S tím já souhlasím, pokud je presenter jednoduchý tak problém nebude. Při dalším rozvoji presenteru ale k chybě dojít může díky tomu, že cachování je schované (popisuje @mystik).

Cachování můžeš zachovat, ale do property presenteru:

class ArticlePresenter extends BasePresenter
{
   private Selection $articles;

   public function __construct(
      private ArticleModel $articleModel,
      private ArticleMenuFactory $articleMenuFactory,
   )

   public function actionList()
   {
      $this->articles = $this->articleModel->getList();
      ... // první použití dat
   }

   public function renderList()
   {
      $this->template->articles = $this->articles; // druhé použití dat
   }

   public function createComponentArticleMenu(): ArticleMenu
   {
      $this->articleMenuFactory->create(articles: $this->articles); // třetí použití dat
   }
}

Data se cachují, ale přehledným způsobem.

Bohužel nám toto nabourává jiný doporučovaný návrhový vzor a sice delegování práce presenteru do komponent, kdy factory dodá komponentě služby které potřebuje nezávisle na presenteru. Takhle jak jsem to napsal totiž data komponentě dodává presenter.

Bohužel pro často se vyskytující případy kdy více komponent využívá stejná data ideální řešení neexistuje:

a) data dodáme opakovaně z modelu – sql bude duplicitní
b) zacachujeme data v modelu – nepřehledné
c) data cachujeme v property presenteru – komponenta nebude nezávislá

I když nejde splnit všechny dobře míněné návrhové vzory současně, protože se vlastně navzájem vylučují, tak třeba řešení c) vůbec špatné není a pokud se komponenta přesune do traity tak skoro ideální.

Asi záleží jak člověk potřebuje, ale kešování v presenteru jsem ještě nedělal nikdy. Ale i třeba vytváření komponent v Presenter lze → doporuji přečíst https://f3l1x.io/…te-sablonach

Díky všem, bylo to poučné i náročné.

Editoval Klobás (31. 3. 2023 14:50)

m.brecher napsal(a):

@Klobás

doporuji přečíst https://f3l1x.io/…te-sablonach

+ jak psal @mystik :

Injectnuta nette Cache a volani metod z Repository se v nekterych pripadech hodi do cache. Obvykle resim jen sem tam pro veci jako ciselniky.

V obou případech to tam sice není jasně napsané, ale dělá to na mě dojem, že autoři cachují na delší dobu nějaké složité dotazy – třeba dny/týdny, že se tam nemá na mysli cachování v rámci jednoho requestu. Ty dotazy mohou za sebou následovat v řádu milisekund. Má smysl na tu dobu to ukládat do cache úložiště a zase z něj číst ?? Řekl bych že smysl má to uložit do proměnné v RAM paměti – na tak krátkou dobu – tedy property presenteru nebo nějaká proměnná v modelu.

Ano. Víceméně se tu řeší jak kešovat a moc to nesouvisí s tím jak přesně píšeš: cachování v rámci jednoho requestu.
Za mě je použití statické property přímo v metodě prostě OK.

@m.brecher Nemam to ORM zatim nikde verejne. Planuju ho mozna casem open sourcovat ale pred tim to bude chtit trochu ucesat a na to sem zatim nemel cas. Pokud bys ale chtel ozvi se mi na mail a poslu ti nejake ukazky jak s tim pracuju.

@mystik

Nette ma i MemoryStorage to pouzivam na cache v ramci requestu.

vidím že mám znalostní mezery a mám co dohánět

Pokud bys ale chtel ozvi se mi na mail a poslu ti nejake ukazky jak s tim pracuju.

Díky, ale zatím to nehoří, asi bude stačit když počkám na veřejný opensource