model

Na limity dibi občas narážím, zejména při hodně dynamickém generování SQL dotazů. Takže je mi jasné, že to další vývoj potřebuje. Ale jestli ji rovnou zapouzdřit v Nette?

To je tak:

1. céčkové API databází zapouzdřují PHP funkce
2. PHP funkce zapouzdřuje IDibiDriver
3. dibi drivery zapouzdřuje DibiConnection (a sekunduje mu DibiTranslator nebo registr Dibi)
4. zkusil jsem experimentálně zapouzdřit i DibiConnection, a to do DibiTable nebo DibiDataSource

Čtvrtá vrsta je asi ta, kterou máš na mysli. Kvůli komunikaci mezi Nette a dibi vznikl interface IDataSource, jeho výchozí implementací je zmíněný DibiDataSource. Zatím jde o velmi hrubý nástřel, vývoj je otevřený. Každopádně mám představu, že na straně Nette budou existovat pouze rozhraní a implementace bude mimo (tedy v dibi, nebo v nějakých add-ons pro jiné DB, …).

David Grudl napsal(a):

Čtvrtá vrsta je asi ta, kterou máš na mysli. Kvůli komunikaci mezi Nette a dibi vznikl interface IDataSource, jeho výchozí implementací je zmíněný DibiDataSource. Zatím jde o velmi hrubý nástřel, vývoj je otevřený. Každopádně mám představu, že na straně Nette budou existovat pouze rozhraní a implementace bude mimo (tedy v dibi, nebo v nějakých add-ons pro jiné DB, …).

Kdyby se ti povedlo, že budou objekty aplikace nesvázané s ORM, tak to by bylo super. Tohle se žádnému php frameworku ještě nepodařilo.

Zřejmě mít doménové objekty zvlášť a ty by si volaly ORM pouze jako service persistentního úložiště v případě potřeby. Nicméně mě ani po několika nocích nenapadlo, jak by to použití mohlo vypadat, aby to programátora neobtěžovalo spoustou kódu a bylo také možné kdykoliv jednoduše switchnout ORM třeba na object-xml-mapper apod. Možná právě o to se snaží v php pomocí SDO http://cz2.php.net/…book.sdo.php

Spíš bych si to představoval nějak tak, že v presenteru zavoláš metodu doménového objektu např:

$User->getUser('franta') nebo nějak jako $User->_manager->getUser('franta') nebo třeba $System->getUser('franta') to je asi v celku jedno.

A v té metodě se pak zavolá:
$storage->getUser($name)

kde $storage je objekt ORM, v jehož metodě pak může být něco jako:

$db->getUserByName($name)

Když vyměníš storage třeba za xml, tak si ho jen zinicializuješ jinym mapperem a v doménových objektech nic neměníš.

Ale je to prostě spousta psaní pro programátora navíc a samozřejmě by se mělo ošetřit to, aby se nedělaly zbytečné dotazy do databáze, pokud už data v doménovém objektu jsou. Možná to nějak honit přes settery a gettery…

Je tu nebezpečí, že takhle rozgranulované dotazy do databáze ji mohou přespříliš zatěžovat.

Přemýšlel sem, že pěkná optimalizace by byla, kdyby by se celá databáze uložila do paměti pomocí memcache. Při zápisu do databáze by pak měla běžet transakce ohraničující zápis do db tak aktualizování memcache. Samozřejmě nepoužitelné u statistických tabulek nebo databází s GB dat. Na nějaké stovky mega dat, by ale možná šlo.

Take by se mi neco podobneho libilo. Ale chybi mi poradny napad. Zatim mi vyhovuje to co mam. Tz DBModely (s transformArray, ktere mi mapuje atribut modelu na sloupecek v tabulce) a k tomu DBService, ktera mi poskytuje getByXYZ, insert, updateByPK atd…

Ohlede prepnuti do XML by to bylo urcite zajimave, ale nevidim v tom zvlastni vyuziti pro bezici aplikace. Mozna pro vytvoreni nejakych malych app, kde nasazeni DB neni nutne/mozne.

Nedovedu si totiz predstavit jak by se nad XML delaly slozitejsi dotazy. getByPK insert updateByPK jsou jasny, ale neco s GROUP BY, MAX, atd by bylo vykonove asi v …, i kdyz otazka zni zda u malych projektu by neco takoveho bylo nutne.

Jeste drobnost. Nekde jsem kdysi potkal „DB v PHP“. Byly to serializovany pole s daty, ktere se insertly a jen se s nima nejak pracovalo pres klice v poli co foreach atd. Celkem pekne zneuziti PHP. Insert jen doplnil pole a ulozil zpet na disk.