Kde pracovat s db model nebo presenter?

Aha, super díky :)

Je tedy správná cesta řešení toto?

app/model/Sluzby.php

namespace App\Model;
use Nette;
class Sluzby extends Nette\Object{

    /** @var Nette\Database\Context */
    private $database;

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

    function selectTable() {
        return $this->database->table('sluzby');
    }
    public function getAll() {
        return $this->selectTable()->fetchAll();
    }
}

app/presenters/HomepagePresenter.php

namespace App\Presenters;

use Nette;
use App\Model;

class HomepagePresenter extends BasePresenter {
    /**
     * @inject
     * @var \App\Model\Objednavky
     */
    public $objednavky;

    public function renderDefault() {
        $this->template->objednavky = $this->objednavky->getAll();
    }

}

Díky za odpověď.

@vosik199 Ahoj, smer mas dobry. Psal jsem na toto tema clanek do dokumentace, ale jeste neni final … ocenil bych, kdyby jsis ho precetl a pripadne rekl cemu tam neni rozumet :) https://github.com/…ll/271/files

diky

@vosik199 V dokumentaci k Nette asi není potřeba opisovat věci, který najdeš jinde (jak navrhovat třídy, co je model a k čemu slouží, …).
Já mám třeba v každým konkrétním modelu proměnnou, která udává název tabulky, z který se vytahuje při těch generickým metodách (findAll, findByPrimary, getTable).
Lepší by asi bylo udělat interface na modely s metodou, která by jen vracela název té tabulky.

interface IRepository
{
	/**
	 * @return string
	 */
	function getTableName();
}

class Sluzby extends BaseRpository implements IRepository
{
	/**
	 * @return string
	 * @internal
	 */
	public function getTableName ()
	{
		return 'sluzba';
	}
}

class BaseRepository extends Nette\Object
{
	/**
	 * @var Nette\Database\Context
	 */
	protected $db;

	/**
	 * @param Nette\Database\Context $db
	 */
	public function __construct (Nette\Database\Context $db)
	{
		$this->db = $db;
	}

	/**
	 * @return Nette\Database\Table\Selection
	 */
	protected function getTable ()
	{
		$this->getTable($this->getTableName());
	}
}

edit: přejmenováno na repozitář

Editoval CZechBoY (12. 12. 2015 22:13)

Není dobré pojmenovat ty třídy Model. Model je většinou jen jeden a je to celá logika aplikace. Pokud by bylo více modelů, bylo by to třeba model pro sklad, model pro nákupy apod. (Zjednodušeně se dá za model považovat celá logika nad jednou databází, ale kromě databáze i veškeré další rutiny.) A ty by spolu komunikovaly jen pomocí definovanych rozhraní. Navíc model dělá spoustu jiných věcí, než práci s databází.

Tomu, co popisuje @CZechBoY, se většinou říká Repository, nebo DAO. Případně obecně Service.

Casto vidim, ze se Repository pouzivaji pouze pro jednu konkretni db tabulku. Jenze i v pripade nejake tabulky article urcite budu mit dalsi tabulky s autory, tagy apod. A casto se stane, ze potrebuju vytahnout vetsinu souvisejicich informaci.

• Nacist si nejprve pres ArticleRepository data clanku a pak pres AuthorRepository a TagRepository postupne dotahovat zbytek mi prijde jako spousta zbytecne rezie navic. Nemluve o vykonu. Mit tisice/miliony zaznamu, tak to sakra pocitim.
• Mnohem logictejsi a vyrazne rychlejsi je poslat do db kompletni query, nechat ji zpracovat a zpatky dostat kompletni data. No a porad mi dava smysl, ze prave tohle resi ArticleRepository.
• Horsi je, ze nekdy potrebuju vytahnout nazev clanku, perex a tagy. Jindy potrebuju jeste obsah a autora. To uz se mi ArticleRepository zacina rozrustat o X vyberovych metod, nebo tam musi byt nejaky konfigurovatelny datasource, ktery pouzije Service/Facade nad Repository.

Mam to v hlave poskladane spravne, nebo opravdu pouzivate jeden Repository prave pro jednu tabulku a nejakou rezii nad tim?

Editoval suwer (2. 1. 2016 15:14)

Šaman napsal(a):

Repository by měl být pro jednu entitu. Ta může být rozlezlá po více tabulkách. (Nebo dokonce více entit v jedné tabulce a pak bude několi repozitářů pracovat nad stejnou tabulkou).

To je asi to hlavni. Uvedomit si, ze entita nerovna se jeden radek v jedne tabulce, ale odrazi realitu. Tedy objekt, ktery opravdu potrebuju k praci. Takhle mam pokrytou vetsinu pripadu. Zbytek uz jsou velmi, velmi specificke problemy.