Přístup k databázi v modelu (jak to udělat správně?)

Díky za odpověď, v config.neon po doplnění vypadá takto:

services:
	- App\Model\ArticleModel
	- App\Model\UserManager
	- App\RouterFactory
	router: @App\RouterFactory::createRouter

Bohužel výsledkem je stále stejná chyba.

Tady to je, vycházím z čistého sandboxu:

config.neon

parameters:


php:
	date.timezone: Europe/Prague


nette:
	application:
		errorPresenter: Error
		mapping:
			*: App\*Module\Presenters\*Presenter

	session:
		expiration: 14 days


database:
	dsn: 'mysql:host=localhost;dbname=test'
	user: 'test'
	password: ''
	debugger: true
	explain: true
	reflection: discovered
	autowired: true
	options:
		lazy: yes


services:
	- App\Model\MessagesModel
	- App\Model\UserManager
	- App\RouterFactory
	router: @App\RouterFactory::createRouter

BaseModel.php

<?php

namespace App\Model;

use Nette;

class BaseModel extends Nette\Object
{
    /** @var Nette\Database\Context */
	private $database;

	public function __construct(Nette\Database\Context $database)
	{
		$this->database = $database;
	}

}

?>

MessagesModel.php

<?php

namespace App\Model;

use Nette,
	Nette\Database\Context,
	Nette\Utils\Strings;



class MessagesModel extends BaseModel
{

	public function __construct(Nette\Database\Context $database)
	{
		parent::__construct($database);
	}

	public function doSomething()
	{

		$this->database->query('SELECT * FROM table WHERE valid >= ?', $start)->dump();

	}

}

?>

MessagesPresenter.php

<?php

namespace App\Presenters;

use Nette,
	App\Model;


class MessagesPresenter extends BasePresenter
{


	public function renderDefault()
	{
		$this->template->anyVariable = 'any value';
	}

	public function renderSomething($type)
	{


		$ml = new \App\Model\MessagesModel();
		$ml->doSomething();

	}

}

?>

Takže nakonec je problém v tom presenteru ;-)
Pročti si tohle.

Jde o to, že ty vytváříš instanci objektu pomocí new \App\Model\MessagesModel();. Problém jsou ty závorky, v nich je to, co očekává constructor toho MessageModelu. Pokud by jsi využil Nette autowire, tak ti tam Nette ty závislosti doplní automaticky. Můsíš si o to jen říct ideálně v constructoru toho presenteru. Takže by to potom vypadalo takhle:

namespace App\Presenters;

use Nette,
    App\Model;


class MessagesPresenter extends BasePresenter
{

	// Nette autoamticky podle tipy hintu pozná jakou službu voláš (proto musí být v config.neonu)
	// a předá jí všechny závislosti, které potřebuje (taky musí být v neonu)
	function __construct(App\Model\MessageModel $messageModel)
	{
		$this->messageModel = $messageModel;
	}

    public function renderSomething($type)
    {
        $ml = $this->messageModel;
        $ml->doSomething();

    }

}

Oli napsal(a):

Takže nakonec je problém v tom presenteru ;-)
Pročti si tohle.

Jde o to, že ty vytváříš instanci objektu pomocí new \App\Model\MessagesModel();. Problém jsou ty závorky, v nich je to, co očekává constructor toho MessageModelu. Pokud by jsi využil Nette autowire, tak ti tam Nette ty závislosti doplní automaticky. Můsíš si o to jen říct ideálně v constructoru toho presenteru. Takže by to potom vypadalo takhle:

namespace App\Presenters;

use Nette,
    App\Model;


class MessagesPresenter extends BasePresenter
{

	// Nette autoamticky podle tipy hintu pozná jakou službu voláš (proto musí být v config.neonu)
	// a předá jí všechny závislosti, které potřebuje (taky musí být v neonu)
	function __construct(App\Model\MessageModel $messageModel)
	{
		$this->messageModel = $messageModel;
	}

    public function renderSomething($type)
    {
        $ml = $this->messageModel;
        $ml->doSomething();

    }

}

Neměly by se do presenterů přidávat závislosti spíš injectem než konstruktorem? https://phpfashion.com/…-presenterum
A neměl by se volat parent::__construct()?

Editoval Azathoth (2. 11. 2014 16:24)

Děkuju všem za odpovědi, to je masakr :-)

Snad se tim nějak prokoušu.

@MartinitCZ asi jsi myslel mě, ne? :-)

Záleží na preferenci. Pro mě to je Kdyby/Autowire (jednoduchost, přehlednost) → konstruktor (správnost, přehlednost) → inject metoda (správnost, nepřehlednost) → inject anotace (jednoduchost, nezapouzdreni objektu).

Pokud zapomene na parent:: tak jestli se musí zeptat, tak to nesouvisí s Nette, ale s OOP a jen pro něj dobře, že se to doučí. ;-)

Druhá věc, já jsem parent v presenteru nepoužil nikdy. Jestliže mám presenter, ze kterého se dědí, konstruktor v něm vůbec nevolám…

Poslední věc, jestli je tu na toto téma postů dost, tak si to můžou přečíst a jsou bez problému, ne?

tak ono to není je o zapomenutém parent::, ale problému kolem dědění.
Cpát si do HomepagePresenteru přes __contructor 4 služby jen proto, že 2 potřebuje BasePresenter musí být zábava. ;)

@MartinitCZ Však k tomu ty injecty máme, abychom si usnadnili vkládání závislostí do abstraktních presenterů (MessagesPresenter extends BasePresenter v dotazu zrovna moc abstraktně nevypadá, tak proč by nemohl použít konstruktor?), ale to pořád není důvod se konstruktoru úplně vyhnout. Já mám na to jednoduchý postup:

• Je presenter abstraktní? Budu od něj dědit? Pak použiju inject metodu(y).
• Je presenter finální? Nebudu od něj dědit? Pak použiju konstruktor.

Vidíš v tomto způsobu práce snad nějaký problém? Já nikoliv, vidím akorát o něco čistší kód. Když zapomeneš po změnách smazat cache a všude cpeš injecty, tak ti aplikace spadne až ve chvíli, kdy se závislostí začneš pracovat (což může klidně být až třeba v signálu nebo akci a nemusíš si toho hned všimnout – o den později se k tomu vrátíš a pak hodinu řešíš, proč ti to nejede, když vlastně kód máš správně). Pokud máš závislosti v konstruktoru, tak si toho všimneš ihned, protože se ti presenter odmítne nainstancovat. Proto si myslím, že je dobré najít zlatou střední cestu a pokud možno používat konstruktor všude, kde je to možné, tedy v konkrétních presenterech.

A parent::__construct() bys měl správně v konstruktoru volat vždy, ale přiznávám, že to také nedodržuji.

Editoval Zax (3. 11. 2014 0:47)

Presentery by měly být jen abstraktní a finální.

Šaman napsal(a):

Presentery by měly být jen abstraktní a finální.

A co když chci používat https://github.com/Kdyby/Aop na presentery?

A proč by měly být presrntery finální?

@jenicek no, je to něco navíc, že je nějaká třída finální, tak se ptám, k čemu je to dobré a proč by se to mělo dělat. Pochopím, proč by se měly dělat abstraktní presentery, ale uniká mi důvod, proč by neabstraktní presentery měly být finální.
A nějak jsem asi nepochopil tvou poznámku, V čem dědění není žádná výhra?

@Azathoth Proč bys chtěl dědit konkrétní presenter? Pokud ve dvou presenterech potřebuješ podobnou funkčnost, tak to jim radši vytvoř samostatný BasePresenter. Pak máš jistotu, že když změníš konkrétní presenter, neovlivníš tím ten druhý presenter. Pokud potřebuješ změnit nějakou společnou funkčnost, sáhneš do toho base. Nevidím nikde potřebu dědit konkrétní presenter.. A klíčové slovo final je prostě jen nástroj pro větší striktnost, který ti dědění zabrání.