DI – Modely a jejich vztahy – best practice

Všechno přeci nejde zapisovat v config texťáku. Třebas takový jazyk, ten se inicializuje takto (z čehož je jasné, že to musí dělat presenter a předat výsledek DI Containeru):

<?php
namespace Base;

class FrontPresenter{

	/** @var persistent */
	public $lang;

        public function startup(){
                parent::startup();
                $this->context->addService('language', $this->detectLanguage());
        }

	protected function detectLanguage(){
	      	$languagesModel = $this->getModel(self::MODEL_LANGUAGES);
      		$languages = $languagesModel ->findAll()->fetchPairs("code", "id");
      		// language from URI
      		if($this->lang && isset($languages[$this->lang])){
			$language = $languagesModel->find($languages[$this->lang])->fetch();
      		// detect language from HttpRequest
		}elseif($detected = $this->getHttpRequest()->detectLanguage(array_keys($languages))){
			$language = $languagesModel->find($languages[$detected])->fetch();
      		// cannot detect, use first in array
      		}else{
			$language = $languagesModel->fetch();
      		}
      		return $language;
	}

}
?>

EDIT: ale s tou nevýhodou máš pravdu, ty skryté závislosti, to je hodně nepříjemná skutečnost…

Mimochodem, není někde nějaký example, co umí DIC co je na GITu?

Editoval semtex.989 (1. 12. 2011 15:00)

@22 osobně si nemyslím že detectLang() je jasný kandidát modelu. Ba naopak. Jazyk patří hlavně do prezentační vrstvy, samozřejmě občas se musí zaptat modelu na data v určitém jazyce, ale jeho místo je podle mého názoru v Presenteru.

@semtex.989
No já bych se osobně tomu model loaderu právě raději vyhnul, je celkem v rozporu se samotným DI, hlavní myšlenka DI je: předávej závislosti (setrem nebo v konstruktoru to už je jedno) ale předávej pouze ty závislosti, které jsou potřeba!. Tedy v ideálním případě se podíváš do konstruktoru a ihned vidíš na jakých třídách je závislí, a to je super, nepříjemná okolnos tohot je to, že konstruktor prostě narůstá, nicméně to nic nemění na tom, že to tak je správně. Předat v konstuktoru jeden objekt, který má přistup ke všem objektů není idealní, z toho rozhodně nepoznáte na čem je daný objekt závislí. On už samotný context není ideální, vhodnější by bylo všchny potřebné třídy předávát v konstruktoru presenteru, jenže to je komplikované, tak se to řeší contextem. Nicméně tím že vytvoříte modelLoader který umí „všechno“ a předáváte ho každému objektu rozhodně nejdete cestou správného DI. To už si to můžete rovnou předávat staticky, to je jen o trochu horší. To jen na doplnění, jinak souhlasím s tím že by se vše mělo psát do config.neon.

Domnívám se, že detekci jazyku by si měl zajistit presenter. Pokud by měl model přistupovat k httpRequestu, bral bych to jako porušení logiky (model spoléhající na persistentní proměnnou presenteru), navíc potomci base presenteru mohou tuto metodu přepsat dle potřeby.

No zkusím to pomocí samotného DI auto-wiringu.

1.) Předpokládám tedy, že si mám vytvořit DI container s továrničkami. Ty modely, které továrničku nepotřebují se budou vytvářet přímo instanciováním třídy.

2.) Presenter bude k modelům přistupovat takto:

<?php
$languagesModel = $this->context->modelsContainer->language;
?>

Otázkou mi je, jak config.neon přimět k tomu, aby mi pro služby modelu vytvořil samostatný kontejner
(nacpat služby modelů do systémového kontejneru je asi blbost)

Editoval semtex.989 (1. 12. 2011 18:38)