Portál AbcLinuxu, 24. dubna 2024 23:07
Ahoj, píšu v PHP aplikaci, která bude přes SOAP komunikovat s klientem, který bude v příkazovém řádku. Hodiny jsem strávil přemýšlením o používání různých návrhových vzorů pro všechny možné účely - DI, data mapper, active record, factory, ... Chtěl bych co nejjednodušeji vyřešit typově následující situaci:
Databáze v postgresql
třídy:
Plan, Kroky
- v tabulkách v databázi je uložený nějaký plán, který obsahuje nějaké kroky. V databázi realizované několika tabulkami. V PHP chci přímo pracovat s plánem jako celkem => vytvořit plán, uložit/načíst z/do databáze.
Přikláním se k tomu, řešit to takto:
Třída Plany: - vytváří nové - načítá z db - ukládá do db Poté práce s ní cca takto: Application::getInstance()->getPlany()->...To je v podstatě kombinace Data Mapper s Factory. Jenže to by teoreticky nemělo být a data mapper by zase měl pracovat jen s jednou tabulkou. Nejsem zastáncem používání "zrovna frčících" návrhových vzorů, které po přečtení různých článků stejně každý používá tím svým jediným "správným způsobem". Rád bych to udělal co nejjednodušší, aby se mi to pak dobře upravovalo. Nějaká ohromná vrstevnatá architektura by mi podle mě spíš přidělala práci. Jenže zase s tímto nemám nějaké zkušenosti. Rád si nechám poradit. Jak byste to řešili vy?
20.11.2014 10:14
Konqui | skóre: 18
| blog: Konqui
| Rožnov pod Radhoštěm
20.11.2014 19:16
Application::getInstance()->getPlany()->$this.
getPlany() je takové ošklivé. Lepší je mít objekt ve stylu úložiště (manager), které bude mít metodu na nalezení plánu a na získání seznamu plánů podle daných kritérií. Většina implementací ORM a podobných módních zvrhlostí jsou v tomhle dost nešikovné.
Dále pak to moc nepřeháněj s operátorem '->', neboť takový řetěz mnoha a mnoha volání je často obtížné dešifrovat.
try {
$plan = $this->planManager->findPlan($plan_id);
foreach ($plan->steps as $step) {
// ...
}
}
catch (PlanNotFoundException $ex) {
// ...
}
$filters = $_GET; // něco v tom smyslu
$list = $this->planManager->listPlans($filters);
if (empty($list)) {
echo "Nejsou.\n";
} else foreach ($list as $plan) {
echo "<li>", $plan->title, "</li>\n"; // jen pro ilustraci
}
// Vytvoření a uložení plánu do XML dokumentu
Plan::getInstance(XMLPlanManager::getInstance(), XMLStepManager::getInstance())
->name('Plan 9)
->addStep('Krok 1')
->addStep('Krok 2')
->addStep('Krok 3')
->save();
// a nebo
Plan::getInstance(PDOPlanManager::getInstance(), PDOStepManager::getInstance())
->name('Plan 9)
->addStep('Krok 1')
->addStep('Krok 2')
->addStep('Krok 3')
->save();
PHP Fatal error: Class 'Plan' not found PHP Fatal error: Class 'XMLPlanManager' not found PHP Fatal error: Class 'XMLStepManager' not found PHP Fatal error: Class 'PDOPlanManager' not found PHP Fatal error: Class 'PDOStepManager' not found
Do testů dávám úmyslně i chybné SQL dotazy, dotazy na neexistující sloupce, neexistující metody apod. a aplikace si s tím musí poradit. Je to užitečnější, než všechna statická typování dohromady.Z mého pohledu zbytečné, rozumný staticky typovaný jazyk by vás toho ušetřil.
SELLECT * FROM tabulkaVždyť to vůbec není v jeho kompetenci. Testy jsou nezbytné.
To by mě zajímalo, jak by se třeba takový kompilátor Javy vypořádal s SQL dotazemPrávě proto jsem psal slovo "rozumný". Staticky typované jazyky s makry nebo něčím podobným – např. poskytovateli typů (type providers) to dokáží. Pár konkrétních příkladů:
I po kompilaci se přece může stát, že mi někdo změní strukturu databáze.Ano, pak bude vyhozena výjimka a aplikace s ní naloží jako s kteroukoli neodchycenou výjimkou – tj. stále nevidím důvod, proč testovat chybné SQL dotazy. Přijde mi to podobné, jako byste testoval, co se stane, když některé metody zmizí nebo se jim změní signatura.
Jak může ta třída v F# tušit, jaké budu dělat dotazy?Je podporována pouze podmnožina SQL dotazů. Kromě toho ta třída dovoluje volat uložené procedury.
Jak se takový F# modul přidává do javovské aplikace?Těžko.
Ano, pak bude vyhozena výjimka a aplikace s ní naloží jako s kteroukoli neodchycenou výjimkouPokud aplikace vyhazuje výjimky, musím v ní i testovat, jestli je vyhazuje správně a jak se při zachytávání výjimky chová. Aplikace nemusí dělat nic z toho, co není testováno.
Přijde mi to podobné, jako byste testoval, co se stane, když některé metody zmizí nebo se jim změní signatura.To samozřejmě testuji také.
Podmnožina mě nezajímá. Chci kompletní sadu SQL dotazů.Jak může ta třída v F# tušit, jaké budu dělat dotazy?Je podporována pouze podmnožina SQL dotazů.
V tom případě F# vypadává ze hry.Jak se takový F# modul přidává do javovské aplikace?Těžko.
Opět byste si ušetřil práci, kdybyste použil rozumný jazyk.Přijde mi to podobné, jako byste testoval, co se stane, když některé metody zmizí nebo se jim změní signatura.To samozřejmě testuji také.
V tom případě F# vypadává ze hry.Podobné věci má i Scala – viz sqlτyped.
Opět byste si ušetřil práci, kdybyste použil rozumný jazyk.Neexistuje žádný "rozumný jazyk", který by sám otestoval logické chyby. Jednotkové testy mohu z editoru spouštět třeba 5× za minutu, klidně i po každém napsaném řádku. Vyvíjet něco pro Javu, Scalu nebo pro F# jen proto, abych to nakonec převedl do požadovaného PHP? To je příliš velká oklika. To už je daleko jednodušší naučit můj editor generovat SQL dotazy reflexí z testovací databáze a pak si je upravit dle aktuální potřeby.
Neexistuje žádný "rozumný jazyk", který by sám otestoval logické chyby. Jednotkové testy mohu z editoru spouštět třeba 5× za minutu, klidně i po každém napsaném řádku.S tím souhlasím. Já ale mluvím o něčem jiném. A to, že existují určité vlastnosti, které může snadno ověřovat kompilátor, tudíž je zbytečné je testovat, stačí jen použít vhodný programovací jazyk.
Je zbytečné hledat vhodný jazyk, stačí testovat. Kompilátor stejně neověří vše, co ověřit potřebuji.Testování bohužel nestačí – příkladem jsou nedeterministické programy nebo programy, jenž nejste schopen otestovat na všech možných vstupech. Na druhé straně ověřovat všechny vlastnosti pomocí typového systému je velmi nákladné. Proto se používá kombinace obojího. Ostatně výhod statického typování si všiml i autor Pythonu.
Testy jsou prostě jednodušší na použití, než nějaké metaprogramování přes dekorátory.To není přes dekorátory. Je to kód, který se spouští při kompilaci a vygeneruje jiný kód. V principu je to velmi jednoduché.
To není přes dekorátory. Je to kód, který se spouští při kompilaci a vygeneruje jiný kód. V principu je to velmi jednoduché.Takže v principu ten kompilátor F# dělá totéž, co lepší editor pro libovolný jazyk.
Takže v principu ten kompilátor F# dělá totéž, co lepší editor pro libovolný jazyk.V tomto případě ano. Výhodou je nezávislost na editoru. Kromě toho si to umí poradit i se situacemi, kdy je informační zdroj příliš rozsáhlý a kdy by generovaný kód byl příliš velký (dokonce to může fungovat i v případech, kdy počet metod nebo počet typů není omezený).
Že se ani jeho struktura nevejde do RAM?Ano, ta struktura může být klidně nekonečná.
The second option, code generation, is also problematic: it adds yet another step to the build process, which means that automated builds must have the tool or its artifacts, it interacts badly with source control, particularly when the generated code is large and should be cached and shared among a development team, and it leads to either code bloat or the need for (yet another!) tool for pruning the compiled artifacts*. * Note that this last point is not a hypothetical: the authors have been informed of cases where the generated code for an enterprise system is so large that it cannot fit within the limits of a .NET process.
data.Society.Government.Politicians.IndividualsAZ.V.``Václav Havel``.Education.
To je sice hezké, ale pořád to nemá šanci se vypořádat s generovanými SQL dotazy, kterých je dle mé zkušenosti ve webových aplikacích značná část.Co myslíte generovanými SQL dotazy?
Koukal jem do různých zdrojáků různých opensource PHP projektů a tam se dost často objevovalo něco ve stylu AplikacniKontejner::getDatabase(), ...Jo, když se začalo více mluvit o návrhových vzorech, singleton byl jedním z těch základních. Chvliku trvalo, než lidem došlo, že to vlastně až tak dobrý nápad není. Dnes už je považován za anti-pattern.
Pokud bych měl takto "schovaný" PlanManager, kde by vznikaly nové plány?Ten PlanManager by měl mít factory metodu na vytváření nových plánů. V jednoduchém případě to bude jen vracet
new Plan($this). Často je žádoucí (ale ne vždy), aby takový objekt znal svého tvůrce a mohl ho používat (proto to $this). Sám uvidíš, co novému plánu bude potřeba předat.
$configuration = new Config();
$container = new AppContainer($configuration);
$container->getServiceSoapServer()->run();
AppContainer {
...
public function getServiceSoapServer() {
// ... testovani zda instance soap serveru existuje ... pokud ne pak:
return new SoapServer($this->getServicePlanManager(), $this->getServiceXY(), ...)
}
...
uvnitř SoapServer:
$this->planManager->create()
...
$this->planManager->findById()
...
}
To už vypadá lépe. Nebo mi něco uniká :) a dělám někde brutální chybu v nepochopení patternu?
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.