Proč neposílat do komponenty presenter?
- Maekoboss
- Člen | 36
Ahoj chci se zeptat nette zkušenějších proč se neposílá do komponenty celý presenter ale jenom například model. Ptám se protože dělám složitější komponentu ve které potřebuju objekt user, $basePath, model, redirectovat, nějaké další proměné z presenteru atd. Tak proč bych měl posílat tyhle věci zvlášť, když si můžu do komponenty poslat celý presenter a pracovat se vším co potřebuju pod jednou proměnou? Napadá mě 1 problém – rychlost.
K rychlosti nevim jak přesně funguje php, ale v Jave se posílá pouze
reference na instanci objektu (odkaz na umístění v paměti),
předpokládám, že stejně to funguje i u php. Takže teoreticky když chci
něco zapsat do modelu a zapisuju to
1. V presenteru přes
$this->context->model->dotaz()
2. V komponentě do které jsem poslal model přes
$this->model->dotaz()
3. V komponentě kam jsem poslal presenter
$this->presenter->context->model->dotaz()
Tak by rychlost měla být srovnatelná. Nebo se pletu?
Jsou nějaké problémy při posílání celého presenteru nebo ne? Jaké s tím máte zkušenosti?
Díky za reakce!
- Jan Endel
- Člen | 1016
Protože se v novém Nette všeobeně od contextu ustupuje jakožto zbytečném mezičlánku i v presenterech (viz v novém Nette metoda injectFoo()), plus o problému Klavíru a doutníku mluvil na jedné z posobot i David Grudl
- ViPEr*CZ*
- Člen | 814
Maekoboss napsal(a):
pilec wrote:
Presenter posílat nemusíš, v Nette\Application\UI\Control komponentě je po připojení dostupný pod
$this->presenter
ale rozhodně bych z něho netahal model přes context.Můžeš trochu objasnit důvody proč? Omlouvám se, ale nerad slepě věřím doporučením, Díky :)
No například co když tu komponentu někomu otevřete? Asi bych čuměl jak blázen a musel zbytečně studovat co se to tam uvnitř vlastně děje.
- Vojtěch Dobeš
- Gold Partner | 1316
Kupříkladu redirectování v komponentě tuto komponentu beznadějně
svazuje s konkrétní aplikací, konkrétními presentery atd… (asi kromě
redirectování na this
), takže to pak není ani moc komponenta
jako spíš takový nádor :). Obecně je lepší psát kód co nejvíce
„volně svázaný“, tj. předávat si závislosti v konstruktoru či
settery a nerozlišovat, jestli jde o obyč. modelovou třídu, knihovnu,
presenter nebo potomka UI\Control
(komponentu). Snáze se pak
například taková komponenta dá přenést do jiného projektu, jak zmínil
**ViPEr*CZ***, lze ji snadno opensourcovat, snáze se dá pokrýt unitovými
testy, když je potřeba…