jakou použít databázovou vrstvu

Cau,

no pokud jsi nidky nic takoveho nepouzival, tak podle meho nazoru pro Tebe bude nejjednoduzsi vyzkouset dibi, ktere je opravdu velmi primocare a dost jednoduse se da implementovat prave do aplikaci, kde se to hemzi mysql_query a da se zacit pouzivat v podstate uplne stejne.

xxxObiWan napsal(a):

Ahoj, já doporučuju Dibi, začínal jsem na ní a zatím jsem neměl důvod ani chuť od ní odejít jinam.

Nette\Database moc nedoporučuju, je na něm ještě pořád dost práce a dotazy na fóru často končí větou „Toto zatím v Nette\Database není implementováno“.

A taky se pořád něco mění a opravuje ;-)

Pokud s Nette teprve začínáš, tak bych Doctrine nedoporučoval. Pokud dobře navrhneš architekturu, nebudeš mít problém později přejít, ale pro začátek si myslím že budeš mít dost co dělat s Nette, natož ještě řešit složitou db vrstvu :-)

Navíc si myslím, že pro menší věci (běžný osobní/firemní web s administrací) nemají parní mlátičky typu Doctrine cenu. Dibi je jednodušší a zřejmě i rychlejší.

@**Filip111**: dibi je jednoznačně nejlepší volba pro začátečníka.

K Nette\Database jsem velice skeptický. Pokud chceš zkusit vrstvu na tomto principu, doporučuji použít NotORM, ve kterém jsou bugy opravovány v řádu hodin nebo dní, ne měsíců a nemění se ti API pod rukama. Ovšem je tu hodně vysoký WTF faktor. A to psaní dotazů může taky na pár dní zamotat hlavu.

Doctrine vyžaduje velice radikální změnu myšlení a začni po ní pokukovat, až si sám začneš říkat, že psaní SQL tě nebaví a chtělo by to něco více objektového.

@**na1k**: Doctrine není zase taková mlátička, pokud ji umíš používat efektivně :)

Rád bych se zeptal, jak řešíte s dibi metody v modelu… Souvisí to s databázovou vrstvou, proto se ptám přímo tady a může to i samotnému zakladateli pomoci, protože většina napsala, že používá právě dibi.

Vezmu příklad, e-shop, jak vybrat produkty?

Napíšu si metodu getAll v modelu ProductModel:

public function getAll() {
  try {
    return dibi::query('SELECT * FROM [product]');
  } catch(\DibiException $e) {
    // tady vracite svou vyjimku nebo si vystacite s tou od dibi? a nebo je odchytavate az v Presenteru a nebo vubec?
  }
}

A co teď, když budete chtít vybrat omezené množství? Přidáte metodě parametry $limit a $offset nebo si napíšete jinou? Co když budete chtít spolu s produktem vybrat i informaci o kategorii, kde se nachází (JOIN na tabulku s kategoriema)? Další metoda nebo upravujete pořád tu jednu?

Neposkytnul by mi někdo nějakou ukázku svých modelů? :-) Rád bych si v tomhle udělal nějak pořádek a nějak to sjednotil.

Pokud se používá Doctrine, tam asi takový problém právě nebude, teda myslím, že tam to funguje tak nějak „samo“ s použitím fluent interface.

Editoval joe (8. 8. 2011 22:48)

joe napsal(a):

Rád bych se zeptal, jak řešíte s dibi metody v modelu… Souvisí to s databázovou vrstvou, proto se ptám přímo tady a může to i samotnému zakladateli pomoci, protože většina napsala, že používá právě dibi.
…

V Doctrine se k tomu to účelu používá Repository kde se právě píší tyto specifické metody pro různé filtry. Pokud se nejedná o metodu findOneXxx tak se hodí přidávat parametry limit a offset.

A co se týká vyjímek měl by to obstarávat nějaky mapper (v jednodušších konstrukcích by to řešil BaseModel).

Ale hlavně bych se vyhnul volání dibi::foo protože tu máme krásné DI.

Takže u mě by ProductModel vypadal asi takto:

namespace App\Model;

class BaseModel
{
	protected $connection;

	public function __construct(\DibiConnection $connection);

	protected function query($sql)
	{
		try {
			return $this->connection->query($sql);
		} catch (\DibiException $e) {
			if (....) {
				throw new DuplicateEntryException(...);
			} elseif (...) {
				// ...
			} else {
				throw new Excetption;
			}
		}
	}
}

class ProductModel extends BaseModel
{
	public function findAll($limit = NULL, $offset = NULL)
	{
		if ($limit) {
			return $this->query("SELECT * FROM [product] LIMIT ...");
		}
		return $this->query("SELECT * FROM [product]");
	}
}

Já to mam špatně? Jaká je výhoda použití services? (resp. nemáte nějaký odkaz, kde je to trochu vysvětlený – v dokumentaci ani na foru jsem to nijak blíž rozepsaný nenašel a zatím nechápu jejich smysl).

Mám to teď takhle:

common:
	database:
		driver = mysql
		lazy = TRUE
		charset = utf8
development < common:
	database:
		database: misa
		host: localhost
		username: root
		password:
		profiler: true

<?php
$configurator = new Nette\Configurator;
$configurator->container->params += $params;
$configurator->container->params['tempDir'] = __DIR__ . '/../temp';
$container = $configurator->loadConfig(__DIR__ . '/config.neon');

dibi::connect($container->params['database']);
?>

a v modelu pak

<?php
dibi::query('SELECT * FROM [v_content] WHERE [id] = %i', $id);
?>

Co je na tom tak špatnýho? Já tam vidím jen jednu výhodu pro můj zápis…je to kratší.
Díky.

Filip111 napsal(a):

Co je na tom tak špatnýho? Já tam vidím jen jednu výhodu pro můj zápis…je to kratší.
Díky.

Na tu první výhodu narazíš když budeš potřebovat více jak jedno spojení do DB. Na druhou až budeš psát testy.

Pouzivate nekdo CRUD model pres DI? Zajimalo by me, jak vam funguje napovidani IDE anebo jste se ho vzdali?

HosipLan: Dik! To vypada funkcne.

Filip111 napsal(a):

Pročetl jsem něco o DI – začínám tušit, neříkám, že to chápu nebo dokážu používat.
Každopádně si připadam jak looser první den ve škole. Celkově komplikovanost objektů v nette, různé magické volání, abstrakce přes několik úrovní apod. mě dost frustruje :)
(a to nejsem úplnej začátečník – c, delphi, php, sql dělam asi už deset let, v poslední době i abap)

Budu holt dál po večerech číst a psát a snad se to v tý hlavě časem nějak pospojuje…
Díky.

A taky nemusíš do aktuálního projektu nacpat každou novinku nebo techniku na kterou narazíš. Že to nebude úplně puristicky dokonalé je jedno – lepší než kdybys projekt nedodělal (a magické volání by nemělo být nutné používat) a nikdo z něj tak nemohl mít užitek

Patrik Votoček – díky za ukázku, vypadá to dobře. Osobně bych se do dalších abstrakcí nepouštěl, přijde mi to vcelku zbytečné.

Řešení filtrování, omezení (limit, offset) by bylo asi ideální řešit přes DibiFluent, ale radši mám dotazy napsané celé ručně, člověk se v nich vyzná hned a nemusí luštit, jestli se náhodou nevygeneruje trochu jiný dotaz nebo dokonce zbytečně víc dotazů, než je nutné, když by to šlo ručně spojit do jednoho – což je velká nevýhoda ORM frameworků. Aspoň v Javě jsem na to při školní práci narazil.

HosipLan – jak jsem před chviličkou napsal, nevidím důvod si ztěžovat práci takovou abstrakcí, jako jsou například entity. Nebudu z PHP dělat Javu. Asi nejsem takový objektový fanatik a programátor :), abych něco takového dělal.

Editoval joe (9. 8. 2011 21:26)

@HosipLan a jak jinak… copak bych se s tebou mohl porovnávat? Na takové úrovni nikdy nebudu, nerad ale dělám věci, co mně osobně přijdou zbytečné. S programováním jsem začal poměrně brzo (o to víc mě začíná víc a víc nudit :)), tak vím, jak se programovalo dřív. Jsem ze starý školy :) ale když mi to přijde užitečné, dokážu svoje postupy změnit hodně rychle. Vždyť víš, že jsi mi tu už několikrát pomohl a za to jsem vděčný (nejen tobě).

Nox napsal(a):
A taky nemusíš do aktuálního projektu nacpat každou novinku nebo techniku na kterou narazíš. Že to nebude úplně puristicky dokonalé je jedno – lepší než kdybys projekt nedodělal (a magické volání by nemělo být nutné používat) a nikdo z něj tak nemohl mít užitek

Presne tento pocit mam vo svojich zaciatkoch aj ja. Cokolvek spravim, vzapati zistim, ze to nemam uplne ciste a zasa to prerabam a stojim tak dlho na mieste. Riesim samotne nette viac ako projekt.

Nic ti nebrání volat přímo $this->connection (statické dibi::foo(...) jsou v 99% pouze aliasy pro dibi::$connection->foo(...). V mém příkladu šlo hlavně o překlad vyjímek.

Což řeší code completition…