abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 20:00 | Komunita

Spolek vpsFree.cz již potřetí zveřejnil statistiku linuxových distribucí běžících na jejich infrastruktuře. Nejpoužívanější je Debian s 50,4 %. Následuje Ubuntu s 25,6 % a CentOS s 13,6 %. Skokanem roku je Alpine Linux.

Ladislav Hagara | Komentářů: 0
dnes 18:33 | Zajímavý článek

Michal Špaček publikoval třetí číslo svého newsletteru věnovanému bezpečnosti, bezpečnému vývoji převážně webových aplikací a bezpečnosti uživatelů. Věnuje se v něm například také bezpečnostní chybě v ImageMagick.

Ladislav Hagara | Komentářů: 1
dnes 05:55 | Zajímavý projekt

V pátek byl představen projekt postmarketOS (GitHub). Cílem tohoto projektu je open source operační systém pro chytré telefony vycházející z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Operační systém postmarketOS by měl podporovat 10letý životní cyklus chytrých telefonů.

Ladislav Hagara | Komentářů: 28
včera 23:44 | Nová verze

Byla vydána verze 0.4.5 svobodného operačního systému ReactOS. Z novinek lze zdůraznit podporu kancelářského balíku Microsoft Office 2010. Podrobnosti v ChangeLogu.

Ladislav Hagara | Komentářů: 8
včera 23:11 | Komunita

Linphone 4.0 pro desktop přichází. Vývojáři tohoto multiplatformního open source VoIP a SIP klienta postupně představují nové vlastnosti. Verze 4.0 bude postavena na Qt [reddit].

Ladislav Hagara | Komentářů: 0
27.5. 22:22 | Komunita

Dle plánu byl měl Debian 9 s kódovým názvem Stretch vyjít v sobotu 17. června. Po celém světě se začínají plánovat Release Parties. Oznámeno bylo vydání čtvrté RC (release candidate) verze instalátoru pro Debian 9 Stretch.

Ladislav Hagara | Komentářů: 5
26.5. 22:22 | Komunita

V Norimberku probíhá do neděle 28. května openSUSE Conference 2017. Na programu je celá řada zajímavých přednášek. Sledovat je lze online. K dispozici jsou také videozáznamy (YouTube) již proběhnuvších přednášek. Dění lze sledovat na Twitteru.

Ladislav Hagara | Komentářů: 0
26.5. 11:33 | IT novinky

Red Hat kupuje společnost Codenvy stojící za stejnojmenným webovým (cloudovým) integrovaným vývojovým prostředím (WIDE) postaveném na Eclipse Che.

Ladislav Hagara | Komentářů: 0
26.5. 08:55 | Nová verze

V listopadu 2014 byl představen fork Debianu bez systemd pojmenovaný Devuan. Po dva a půl roce jeho vývojáři oznámili vydání první stabilní verze 1.0. Jedná se o verzi s dlouhodobou podporou (LTS) a její kódové jméno je Jessie, podle planetky s katalogovým číslem 10 464.

Ladislav Hagara | Komentářů: 16
25.5. 20:22 | Zajímavý článek

Nadace Raspberry Pi vydala již osmapadesáté číslo (pdf) stostránkového anglicky psaného časopisu MagPi věnovanému Raspberry Pi a projektům postaveným na tomto jednodeskovém počítači a druhé číslo (pdf) časopisu Hello World primárně určeného pro učitele informatiky a výpočetní techniky.

Ladislav Hagara | Komentářů: 0
Chystáte se pořídit CPU AMD Ryzen?
 (6%)
 (32%)
 (1%)
 (8%)
 (44%)
 (8%)
Celkem 636 hlasů
 Komentářů: 62, poslední 19.5. 01:57
    Rozcestník

    Dotaz: PHP - jaký návrhový vzor použít

    20.11.2014 04:56 fp
    PHP - jaký návrhový vzor použít
    Přečteno: 605×

    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?

    Odpovědi

    Konqui avatar 20.11.2014 10:14 Konqui | skóre: 18 | blog: Konqui | Rožnov pod Radhoštěm
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Návrhové vzory nejsou primárně určeny k obecnému použití v přesně daných situacích. Jen nastiňují řešení dané problematiky daným způsobem. V praxi se návrhové vzory přizpůsobují/kombinují/nepoužívají.

    Dobře napsaná aplikace nestaví na definovaných návrhových vzorech, ale bere si z nich příklad a inspiraci.

    Neexistuje nějaké stanovené pravidlo "na tohle použij tenhle vzor", spíše čím více zkušenosti programátor/architekt zná, tím lépe aplikaci navrhne. A to ani moc nesouvisí s návrhovými vzory.
    Open/save dialogy z GTK+ jsou nejkřiklavější ukázkou toho nejdebilnějšího software, co vůbec může existovat.
    20.11.2014 14:25 Ivan Nový
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    nejdříve si navrhněte rozhraní I_Plan s operacemi addStep, removeStep, getSteps, rozhraní I_Model s operacemi find, load, save a rozhraní I_Step s operací find, eval a implementujte je na objektech Plan, Step. Pomocí rozhraní I_Step v konstruktoru třídy Plan předejte konkretní implementaci kroku. Rozhraní I_Model použijete pro práci s tabulkou jak pro třídu Plan, tak pro třídu Step. Tím získáte implementaci nezávislou na uložení dat v konkrétní databázi. Implementaci rozhraní I_Model můžete vyčlenit do tříd PlanModel, StepModel a ty předávat v konstruktoru do třídy Plan, resp. Model. V budoucnosti různými implementacemi rozhraní I_Model, můžete realizovat uložení dat v různých db, nebo typech souborů, klidně v XML pro import, či export atp.
    20.11.2014 14:52 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Tady ještě někdo používá maďarskou notaci? Prefix "I_" se před název interface už nedává. Smysl názvů "I_Plan", "I_Model" apod. mi uniká - nic neříkají o tom, co implementace má umět.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    20.11.2014 15:18 Ivan Nový
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Tak jistě, pojmenování tříd se dá vylepšit. Třeba delší DataModel, a místo Plan, třeba PlanStep ...
    20.11.2014 15:21 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Nepsal jsem o nesprávném pojmenování implementace, ale rozhraní - tedy interface.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    20.11.2014 16:32 Ivan Nový
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Aha, to jsem přehlédl, o názvech rozhraní samozřejmě platí něco obdobného. Jen tak v rychlosti jsem zvolil hodně univerzální názvy, aby příklad zůstal abstraktní.
    Josef Kufner avatar 20.11.2014 19:16 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Application::getInstance()->getPlany()->
    Tohle je špatně hned z několika důvodů.

    V první řadě je špatný nápad používat globální proměnné a singletony (globální proměnná schovaná v objektu). Značí to špatnou/žádnou implementaci dependency injection. Ten výraz by měl začínat na $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
    }
    Hello world ! Segmentation fault (core dumped)
    20.11.2014 19:54 fp
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Implementaci Dependency Injection dělat nechci (i když mi to pořád ještě vrtá hlavou). S DI se teď roztrh pytel a její různé implementace se začaly objevovat vč. takových, že "aplikace se pokusí uhodnout, co tam podstrčit" či "konfigurace v konfiguračním yaml souboru vč. inicializace proměnných". To mi přijde hodně ošklivé. Přehlednějsí mi to přijde bez ní. 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(), ...

    Pokud bych měl takto "schovaný" PlanManager, kde by vznikaly nové plány? Volat přímo v aplikaci "$plan = new Plan(...)" a ten pak předávat PlanManageru k uložení mi připadá takové divné.
    20.11.2014 20:15 Ivan Nový
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    No výhoda toho uspořádání je, že třída, která obklopuje takový PlanManager, je na něm nezávislá, používá jen jeho rozhraní a můžete do ní strčit jakoukoliv variantu PlanManageru. jeden třeba co kroky ukládá v csv, jiný v XML a ještě jiný co je ukládá v MySQL. A k PlanManageru si můžete přidat statickou funkci getInstance a místo new PlanManager můžete volat PlanManager::getInstance() třeba takto
         // 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();
    
    20.11.2014 20:24 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Nic z toho nefunguje...
    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
    
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    21.11.2014 12:14 Ivan Nový
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Tak zase na druhé straně je někdy lepší, tato fatální chyba, která přesně lokalizuje co kde chybí (analogie statického typování), zvláště když máte Plan::getInstance(), použito jen na jednom místě programu, než nějaký DI kontejner, který vám podstrčí někam nějakou kravinu a vy nevíte kde, projeví se to pak třeba jen těžce lokalizovatelnou náhodnou chybou. DI paradoxně z dynamického jazyka PHP dělá statický a ze statického, jako Java, dělá dynamický :-)
    21.11.2014 12:48 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    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.

    Aplikace s DI kontejnerem se obvykle testuje dost blbě, proto DI kontejnery raději nepoužívám vůbec.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    21.11.2014 17:28 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    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.
    21.11.2014 18:05 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    To by mě zajímalo, jak by se třeba takový kompilátor Javy vypořádal s SQL dotazem
    SELLECT * FROM tabulka
    Vždyť to vůbec není v jeho kompetenci. Testy jsou nezbytné.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    21.11.2014 18:56 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    To by mě zajímalo, jak by se třeba takový kompilátor Javy vypořádal s SQL dotazem
    Prá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ů:
    • V OCamlu existuje knihovna PG'OCaml. Při kompilaci se preprocesor připojí k databázi, ověří SQL příkazy a jejich výsledky vhodně natypuje.
    • F# 3.0 má SQL poskytovatele typů, který se umí připojit k databázi a vygenerovat třídu, jenž reprezentuje strukturu databáze. Dotazy na databázi se pak provádí pomocí dané třídy.
    • Podpora pro některé SQL konstrukce je přímo zabudována (příklad) v jazyku Ur/Web.
    21.11.2014 19:30 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Takový preprocesing si raději udělám jako plugin do editoru a nebudu zbytečně kombinovat jazyky a knihovny, které pro výsledek nepotřebuji.

    I po kompilaci se přece může stát, že mi někdo změní strukturu databáze. SQL dotaz, který dosud fungoval, najednou selže. Proto se píší testy, které musí selhat, aby se zjistilo, jak se s tím aplikace vypořádá.

    Jak může ta třída v F# tušit, jaké budu dělat dotazy? Jak se takový F# modul přidává do javovské aplikace?
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    21.11.2014 20:04 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    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.
    21.11.2014 20:56 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Ano, pak bude vyhozena výjimka a aplikace s ní naloží jako s kteroukoli neodchycenou výjimkou
    Pokud 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é.
    Jak může ta třída v F# tušit, jaké budu dělat dotazy?
    Je podporována pouze podmnožina SQL dotazů.
    Podmnožina mě nezajímá. Chci kompletní sadu SQL dotazů.
    Jak se takový F# modul přidává do javovské aplikace?
    Těžko.
    V tom případě F# vypadává ze hry.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    21.11.2014 21:28 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    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é.
    Opět byste si ušetřil práci, kdybyste použil rozumný jazyk.
    V tom případě F# vypadává ze hry.
    Podobné věci má i Scala – viz sqlτyped.
    21.11.2014 21:38 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    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.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    21.11.2014 21:53 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    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.
    21.11.2014 21:58 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Je zbytečné hledat vhodný jazyk, stačí testovat. Kompilátor stejně neověří vše, co ověřit potřebuji. Testy jsou prostě jednodušší na použití, než nějaké metaprogramování přes dekorátory.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    22.11.2014 15:15 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    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é.
    22.11.2014 15:25 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    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.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    22.11.2014 15:51 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    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ý).
    22.11.2014 16:05 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Přiznávám, že jsem na svém editoru závislý. Na druhou stranu mi funguje všude, takže z toho obavu nemám. Nezávislost na editoru nevyměním za závislost na F# - raději budu závislý na editoru než na nějakém kompilátoru, který mi všude nepojede.

    Co je to "příliš rozsáhlý" informační zdroj? Že se ani jeho struktura nevejde do RAM?
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    22.11.2014 19:29 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Že se ani jeho struktura nevejde do RAM?
    Ano, ta struktura může být klidně nekonečná.
    22.11.2014 20:00 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Počet tabulek v databázích nebývá příliš omezen, ale víc než několik tisíc tabulek snad nikdo nedělá. Podobně jako nikdo nedělá stovky sloupců v tabulce (max. desítky). Taková struktura se do RAM v pohodě vejde.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    22.11.2014 19:43 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Ještě dodám citaci z článku Strongly-Typed Language Support for Internet-Scale Information Sources (strana 48):
    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.
    22.11.2014 20:04 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    To je ale jen důsledek chybného návrhu databáze. Nemyslím si, že by to striktně typovaný jazyk mohl nějak zachránit.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    22.11.2014 23:27 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Záleží, jak ta data prezentujete. Například typový poskytovatel pro Freebase nabízí i vlastnosti pro jednotlivé záznamy v databázi. S doplňováním kódu lze tedy psát výrazy data.Society.Government.Politicians.IndividualsAZ.V.``Václav Havel``.Education.
    23.11.2014 00:05 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    To vypadá strašně, ale v NoSQL se to jistě použít dá.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    Josef Kufner avatar 21.11.2014 19:44 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    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.

    Je užitečné kontrolovat očekávanou strukturu databáze proti skutečnosti, ale pokud se to děje při kompilaci, je to na nic, neboť tou dobou to bude mít přístup maximálně na testovací server a struktura produkční databáze se bude měnit až při deploy po otestování.

    Tedy je potřeba mít možnost dle zakompilovaného modelu v aplikaci ověřit aktuálnost databáze, ale nemá smysl z databáze generovat model. Navíc pokud se mění struktura databáze, je obvykle potřeba aktualizovat i data (např. vygenerovat data do nového sloupce, nebo je konvertovat do nového tvaru) a na tom si jakákoliv automatika vyláme zuby.
    Hello world ! Segmentation fault (core dumped)
    21.11.2014 20:09 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    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?
    Josef Kufner avatar 21.11.2014 20:25 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Že si ten select před provedením poslepuješ z malých dílků dle aktuální potřeby.
    Hello world ! Segmentation fault (core dumped)
    21.11.2014 21:11 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Například v F# dostanete pro každou tabulku IQueryable<T>, takže dotazy lze do určité míry skládat z dílků.
    21.11.2014 21:17 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    A k čemu je to dobré, když nepotřebuji interface pro tabulku, ale pro doménu?
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    22.11.2014 14:41 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Je to dobré k pokládání dotazů do databáze.
    22.11.2014 14:53 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Na to mi přece stačí reflexe v editoru.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    22.11.2014 15:17 Radek Miček | skóre: 23 | blog: radekm_blog
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Obávám se, že reflexe nestačí, když je SQL dotaz, slovy pana Kufnera, generovaný.
    22.11.2014 15:35 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Obávám se, že výměna PHP za F# neprojde. F# mi dle popisu nenabízí nic, co by PHP neumělo a navíc na většině hostingů stejně není podporován.

    Byla to jen akademická debata o výhodách statického typování, která mě nijak nepřesvědčila.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    21.11.2014 20:02 Ivan Nový
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    SQL příkazy jsou z hlediska Javy pouhá data a ty mají být uloženy v db a před uložením verifikovány. Něco jako db.execute("SELECT a FROM x"); by se v programu nemělo vůbec vyskytovat. Ale pouze ve formě x.getA() kde teprve to getA příkaz SELECT načte z databáze (třeba ve formě XML souborů). Když princip DI a podobné domyslíte do důsledků.
    Josef Kufner avatar 21.11.2014 18:44 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Vůbec ne. Testy by měly zkontrolovat i to, že program umí slušně selhat, a že hozená výjimka od rozbitého selectu bude řádně zalogována.
    Hello world ! Segmentation fault (core dumped)
    20.11.2014 20:16 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Nepleť si DI s DI kontejnerem.

    Dependency Injection je velmi užitečným vzorem. Jeho implementace je triviální a není k tomu potřebná žádná knihovna.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    Josef Kufner avatar 20.11.2014 20:36 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Tak, tak. "Chytrost" některých kontejnerů je značně protivná a mnohdy víc překáží než pomáhá. Na druhou stranu jednoduchý DI kontejner je jen taková naleštěná factory.
    Hello world ! Segmentation fault (core dumped)
    20.11.2014 20:53 fp
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Jo, už jsem to pochopil, našel jsem pár příkladů a vlastě DI používám jen tím, že nějaká objekt podstrkuji do konstruktoru druhémum, třeba DBConnection. Nicméně asi začnu používat jeden systémový kontejner - ten to sice jen obalí, ale vypadá to líp :-)
    Josef Kufner avatar 20.11.2014 20:39 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    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.
    Hello world ! Segmentation fault (core dumped)
    Josef Kufner avatar 20.11.2014 20:43 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    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.
    Hello world ! Segmentation fault (core dumped)
    20.11.2014 20:03 Ivan Nový
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Možná ještě místo $this->planManager->findPlan() rovnou $this->findPlan(), která by eventuelně využívala $this->planManager
    Josef Kufner avatar 20.11.2014 20:35 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Ne.
    Hello world ! Segmentation fault (core dumped)
    20.11.2014 21:02 fp
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Takže jestli to dobře chápu, implementace by byla nějaká taková:
    
    $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?
    Josef Kufner avatar 20.11.2014 21:31 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Jo, něco takového. Ale moc to s tím kontejnerem nepřeháněj – hodně věcí ho nepotřebuje a vystačí si s jednou věcí z něj.
    Hello world ! Segmentation fault (core dumped)
    20.11.2014 21:37 fp
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Tak teď už to zase nechápu. Když to založím na systémovém kontejneru, který mi dodává závislosti, tak nemá smysl ho nějak obcházet.
    20.11.2014 21:43 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Když máš v ruce kladivo, tak i když všechno vypadá jako hřebík, realita je jiná.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    Josef Kufner avatar 20.11.2014 21:50 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Ten kontejner není nic jiného než kupa globálních proměnných zabalená do vlastního jmenného prostoru. Je to trochu lepší, ale pořád to je hnus.

    Dependency injection se snaží o eliminaci všech takových globálních udělátek. Globální kontejner by tedy měl být používán (pokud vůbec) jen na úrovni front controlleru a v omezené míře na úrovni controlleru. Neměl by (většinou) prosakovat do modelu, ani do view.
    Hello world ! Segmentation fault (core dumped)
    20.11.2014 23:47 fp
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Však o to přeci jde, pracovat s modely. getServicePlanManager vrací právě model a getServiceSoapServer vrací mix(controller,view - nebudu u totoho rozlišovat). Tak je to myšleno, že by se to chovat nemělo? Nebo je myšleno to, že by pak už neměla být další vrstva (další DI kontejner) uvnitř PlanManageru?
    Josef Kufner avatar 21.11.2014 00:22 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Pointa je v tom, že by žádný DI kontejner v aplikaci být neměl a tudíž ani žádné metody jako getServiceCokoliv().

    Nejlepší současné řešení je držet DI kontejner jen co nejmenší a používat ho jen v omezené části aplikace. Tedy že ostatní části přímo dostanou to, co potřebují, a nebudou žádný kontejner používat.

    Ono DI kontejner není žádná výhra a je to pořád celkem mizerné řešení, i když je jedno z nejlepších nyní známých. Snad někdo brzy vymyslí něco lepšího.
    Hello world ! Segmentation fault (core dumped)
    21.11.2014 19:02 Logik
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Osobně jsem dospěl k modelu s IMHO přijatelným poměrem cena/výkon:

    Mám jeden sigleton DI kontejner. A vytvářené objekty jsou napsány s nepovinnými závislostmi tak, že když se neuvedou explicitně, vezmou se z toho singletonu.

    Pro účely unit testů atd... to jde snadno mockovat, a přitom se to dá snadno a přitom člověk může rychle napsat "špinavou aplikaci", když mu nejde o čistotu řešení, ale o rychlost - a ta "špinavá aplikace" jde snadno "opravit".
    Josef Kufner avatar 21.11.2014 19:44 Josef Kufner | skóre: 67
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Jo, toto je takový rozumný přístup a v současné době asi nejlepší. I když k té automatice jsem trošku nedůvěřivý.

    Ale i tak je potřeba si hlídat, kde všude se ten kontejner používá, neboť to kompiluje použití kódu v jiných aplikacích, kde je jiný kontejner.
    Hello world ! Segmentation fault (core dumped)
    21.11.2014 19:53 Kit | skóre: 37 | Brno
    Rozbalit Rozbalit vše Re: PHP - jaký návrhový vzor použít
    Místo DI kontejneru používám model. Namockovat se v něm dá cokoli, protože všechno dostává přes DI.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.