Možná jsi to takhle dřív dělal. Možná že i teď ještě máš radost ze svého kódu. Ale zítra už ne. Protože od teď se budeš pevně opírat o pravidla EMO-programování:

Zatáhni si závěsy, řízni se a nakresli si na tvář slzy

Nechci tě vidět, jak se raduješ. Nechci vidět, že jsi hrdý. Nechlub se mi, kolik metod si dnes napsal. Vůbec mě nedojímá to, který framework jsi zase zkusil. Nechci poslouchat, jak nadšeně dodržuješ principy MVC architektury. Nezajímá mě, kolik řádků kódu jsi dneska napsal.

Zatáhni závěsy

Světlo tě ruší. Ještě stále ti připomíná, jak prozařovalo tvoje štěstí z odvedené práce. Musíš se ho zbavit. Schovej svůj kód před světlem. Světlo svítí nejvíce na nejvyšší vrstvy. Vidíš spoustu doménové logiky ve svém controlleru? Schovej ji do modelů.

Nakonec, až budeš mít v controlleru jen nejnutnější obsluhu, budeš už mít tolik síly, že se ti podaří zvednout se a zatáhnout si závěsy.

Řízni se

Stejně jako již ze tvé tváře nenávratně zmizela radost, musí zmizet i tvé algoritmy, které se na tebe ve tvých modelech smějí každý ze tří stran. Vezmi nůž. Vezmi si ten nejostřejší nůž, který najdeš, a řízni. Seřízni svůj duplicitní kód, vytvoř pro něj zvláštní funkce a tam ho natlač.

Přes bolestný šrám cítíš jisté uspokojení. Není to štěstí. Není to radost. Není to nic z těch pocitů, které jsi do dneška poznal.

Nakresli si na tvář slzy

Nyní již píšeš EMO-kódy. A tvá duše je již stejně prázdná jako kamenný pohled tvých očí. Jsi ve finále. Dnes naposledy vezmeš do rukou klávesnici a na tvář si vytetuješ slzy.

Teprve, až tvůj kolega zítra ráno uvidí tvoje slzy, tvoje slzy připomínající zavináče – ať už budou vypadat jako @param nebo @return nebo ještě jinak – až tehdy pochopí, že EMO-programování je styl, kterým chce žít taky.

„To je oč tu běží.“

William Shakespeare

Doménová logika je zřejmě tou esencí, díky které aplikace píšeme a díky které nikdy nebudeme nezaměstnaní. Jde v podstatě o souhrn veškerých algoritmů, které probíhají v prostoru mezi uživatelským rozhraním a daty.

Pokud pojem doménová logika neznáte, nebojte se, že o něco přicházíte. Stejně ji totiž používáte. Doménová logika není žádná speciální vrstva v aplikaci, na kterou musíte myslet. Není to ani žádný návrhový vzor, který byste se museli učit.

Ke vzniku doménové logiky stačí nechat se vést neviditelnou rukou zadavatele.

A co když jde jen o takové to domácí programování a sepsaná aplikace žádnou doménovou logiku nepotřebuje, protože je prostě úplně blbá a jen ukládá data z formulářů do databáze? Tak to si zas o své aplikaci nemyslete. Aplikace, ač úplně blbá, obsahuje doménovou logiku snad alespoň v tom, že data validuje, vybere, kam je uložit, nebo vám v nich hbitě vyhledává.

Prostě si napište co chcete a tu doménovou logiku tam najdete. Jakto? Protože ta neviditelná ruka funguje a ne že ne!

Tak to prostě neřeš!

Nicméně dobrá otázka je nasnadě. Jaký smysl má o tom spekulovat, když je to taková přirozená věc? Proč o tom přemýšlet, když všechno můžu spočítat v akci controlleru?

Čím více je neviditelná ruka zadavatele lačná po možnostech vaší aplikace, tím se do aplikace dostává doménové logiky více a více. Až najednou člověk zjistí, že jeho controller je dlouhý jak Bible. A co když se neviditelná ruka při zadávání utne a chce nějaký výpočet změnit? Zkoušeli jste někdy upravovat Bibli?

Proto se slovutný guru lidu programátorského Martin Fowler uvolil utvořit přístupy k tomu, jak s doménovou logikou v aplikaci zacházet. Tak vzniklo několik návrhových vzorů, které nám ukazují, kam se kdy vydat a kdy změnit směr, aby se naše doménová logika mohla pod neviditelnou rukou zadavatele dennodenně prohýbat.

Zkuste uhodnout, o čem bude několik příštích článku :)

Furt se někam odkazovat

Typickým příkladem takového problému je ve vývoji webové aplikace vytvoření odkazu. Ubohého vývojáře při psání HTML kódu pro odkaz napadá spousta otázek. Na jakou URL přesně se odkazuji? Jaká je absolutní cesta k aplikaci? A nebude mi stačit relativní? Potřebuji mít na odkazu nějakou třídu? Má mít id?

A jaký bude text odkazu? A co když odkaz něco maže, nemá nejdřív vyskočit dialog pro potvrzení akce?

Smůla, zubožený vývojář je již vyčerpán řešením předchozích otázek natolik, že do odkazu prostě něco napíše. Na přesnou syntax pro confirm si nevzpomene. Ale co, však to jde i bez té prudy.

Udělej to líp. Myslím jednoduše

Takovéto problémy nám většinou vyřeší náš aplikační framework. Ejhle, v Zend Frameworku jsem však očekávaný helper pro vytvoření odkazu nenašel. Nu což, tu je jiný:

class Stepiiik_View_Helper_Link
{
  public $view;

  /**
   * @param name text odkazu
   * @param url array (klice controller, action..)
   * @param array s dalsima moznostma: confirm (text), button (boolean), id (text), class (text)
   */
  public function link($name, $url, $params = null)
  {
    $html = '<a href="' . $this->view->url($url, null, true, true) . '"';
    if (is_array($params)) {
      if (array_key_exists('confirm', $params)) {
        $html .= ' onclick="return confirm(\''.addslashes($params['confirm']).'\')"';
      }
      if (array_key_exists('id', $params)) {
        $html .= ' id="'.addslashes($params['id']).'"';
      }
      if (array_key_exists('class', $params)) {
        $html .= ' class="'.addslashes($params['class']).'"';
      }
      if (array_key_exists('button', $params)) {
        $html .= ' class="button"';
      }
    }

    $html .= '>'. $name . '';

    return $html;
  }
}

A jak vložit odkaz do stránky teď? Stačí mi vědět, jaký bude text odkazu. Znát název controlleru a akce. Popřípadě vědět, jestli má mít odkaz nějaký další atribut nebo potvrzovací confirm.

echo $this->link('Kousnout koně',
  array('controller' => 'kone', 'action' => 'kousnout'),
  array('confirm' => 'Kůň se bude zlobit...'));

Zábava nade vše

Trapně prosté. Leč ono se s tím opravdu o mnoho zábavněji dělá. A náhle aplikace se radostně ptá na každé mazání či jiné nebezpečné kroky. Halt, když tam ten confirm může vývojář vložit bez přemýšlení, tak to udělá. A rád. A vždy.

V práci můžete najít:

• Popis Zend Frameworku a MVC architektury
• Návrhové vzory pro objektově-relační vzory podle Martina Fowlera
• Přístup k objektově-relačnímu mapování v Zend Frameworku
• Možnosti navázání objektů Zend_Db_Table na vrstvu business logiky
• Několik dalších návrhových vzorů týkajících se přístupu k databázi

Práci si můžete také stáhnou. (PDF, 600 kB).

Poměrně dlouhou dobu jsem se snažil takovéto řešení najít. Našel jsem je právě ve chvíli, kdy jsem se smířil s tím, že je vytvořím jako první a budu slavný.

Jmenuje se PEAR:DbDeploy

Knihovnu DbDeploy si můžete stáhnout z SourceForge. V dokumentaci tamtéž naleznete popis instalace.

Nástroj DbDeploy se ovšem zřejmě již nevyvíjí. Ze stránek PEARu lze zjistit, že se zatím do oficiálního PEAR balíku nedostal. Poslední verze je asi 700 dní stará a mírně zabugovaná.

Několik chyb, které mi v použití nástroje bránily, jsem opravil. Bohužel mi licenční podmínky brání opravenou verzi šířit. Pokud mi napíšete, rád vám pošlu alespoň informaci o těch chybách.

Tak se ukaž

Myšlenka nástroje je opravdu jednoduchá. V projektu existuje složka obsahující tzv. delta soubory. Tedy soubory SQL příkazů, které strukturu databáze převedou z verze X na verzi X+1. Soubory jsou pojmenovány podle konvence ve tvaru ‚číslo verze – popis verze . sql‘. Do souboru se zároveň mohou vepsat příkazy, které naopak změny databáze zruší.

alter table kone add column pocet_zubu integer;

--//@UNDO

alter table kone drop column pocet_zubu;

[Poznámka] Reverzní příkazy se sice napsat pouze mohou, nicméně klíčové slovo UNDO je povinné.

V databázi je vytvořena tabulka, do které se ukládá číslo poslední nahrané verze.

DbDeploy obsahuje nástroj pro příkazovou řádku, který se připojí podle parametrů k databázi, načte její aktuální verzi a vytvoří seznam příkazů, který ji převede na verzi nejnovější. Zároveň se vytvoří i soubor, který případně změny vrátí.

dbdeploy -c ./DbDeploy/deploy-devel.ini

Jednoduchost vykoupíme pravidly

DbDeploy je založen na velmi jednoduché myšlence. A proto je potřeba mu vyjít vstříc zavedením určitého workflow.

1. Vývojář musí ukládat SQL příkazy podle daných konvencí. Soubor musí obsahovat klíčkové slovo undo a reverzní příkazy. Musí být umístěn v odpovídající složce a jeho jméno musí začínat číslem o jedničku vyšším, než je číslo posledního souboru. Číslo je nutné při commitu upravit, pokud se v repository objevily nové soubory.
2. Vývojář by měl svou databázi aktualizovat vždy přes DbDeploy, aby se struktura a verze databáze nedostaly do nekonzistentní­ho stavu.
3. Je potřeba striktně zakázat opravování již commitovaných SQL souborů, neboť DbDeploy na již zpracovanou verzi nebude brát znovu zřetel.
4. Vhodné také je, aby vývojáři commitovali SQL soubory co nejdříve. Tj. nejpozději při commitování zdrojových kódů s odpovídající funkcionalitou. Jinak může nadále docházet k situaci, kdy zbytek vývojářů pracuje delší čas na zastaralé verzi databázové struktury.

V tomto workflow jsem však narazil na jednu nejasnost. Ve většině případů měním databázi tak, že příkazy napíšu do souboru, spustím update přes DbDeploy a, pokud vše funguje, soubor commituji.

Problém nastane, pokud nastane chyba. Je pak třeba buďto ručně opravit verzi databáze a spustit znovu opravený soubor nebo vytvořit soubor nový. Protože zřejmě nemá smysl, aby se všem při updatu opakovaly mé chyby, volím téměř vždy první možnost.

Extrémním případem je pak vytváření databázových procedur nebo složitějšího view. Tedy úkonů, u kterých není pravděpodobné, že proběhnou napoprvé správně. Abych při vývoji neztrácel čas neustálím upravováním verze struktury, pracuji zde bez ohledu na popsané workflow. Až finální SQL příkaz nahraji do souboru, stejně jako undo příkaz, který také ručně provedu. Teprve pak soubor commituji a updatuji databázi standardně dle workflow.

Rozvíjej se…

Takto koncipované řešení má pro mě jeden zásadní bonus. V budoucnu umožní zavedení automatického procesu, který dokáže automaticky zpracovat všechny kroky nasazování aplikace. Toto téma zde určitě rozvinu.

Styl mé práce se tím rapidně zefektivnil. Ovšem stejně jsem znovu psal spoustu metod pro vkládání, editování, zobrazování a mazání dat z databáze. A to mě nebavilo.

Tak jsem si napsal abstraktní CRUD controller. Jediné co je nyní potřeba udělat pro napsání správy tabulky databáze je model, formulář a několik šablon.

Chcete to taky dělat rychle?

Jediné, co potřebujete, je stáhnout si nejnovější verzi controlleru z GitHubu. Jedinou třídu, kterou tam naleznete, nahrajete ve svém projektu do adresáře /library/Stepi­iik/.

Jak na to, hm?

Pro názorné vysvětlení práce s CRUD controllerem vytvoříme jednoduchou aplikaci, která schraňovat data o svých oblíbených koních.

Vytvoříme tedy jednoduchou tabulku kone:

create table kone (
    id serial,
    jmeno varchar,
    barva int4,
    constraint kone_pkey primary key (id)
);

[Poznámka] Tabulka je vytvořena v SQL dialektu databáze PostgreSQL.

Nejprve vytvoříme model. Klasicky potomka Zend_Db_Table, který navíc bude umět vrátit číselník barev koní.

class Kone extends Zend_Db_Table
{
        protected $_name = 'kone';

        public static function getBarvy()
        {
                return array(
                        1 => 'Hnědák',
                        2 => 'Bělouš',
                );
        }
}

Druhým krokem bude vytvoření formuláře.

class KoneForm extends Zend_Form
{
        public function init()
        {
                $this->setMethod('post');

                $this->addElement('text','jmeno', array(
                        'label' => 'Jméno',
                        'required' => true,
                ));

                $this->addElement('select','barva', array(
                        'label' => 'Barva',
                        'required' => true,
                        'multiOptions' => Kone::getBarvy(),
                ));

                $this->addElement('button', 'ulozit', array(
                        'label'  => 'Uložit',
                        'ignore' => true,
                        'type'   => 'submit',
                ));
        }
}

Důležité je zde u tlačítka na uložení nastavit atribut ignore na true. Jinak by se aplikace snažila do databáze ukládat i sloupeček ulozit.

Nyní už můžeme vytvořit koňský controller:

class KoneController extends Stepiiik_CRUDController
{
        protected function getModel()
        {
                return new Kone();
        }

        protected function getForm()
        {
                return new KoneForm();
        }
}

Zdá se vám to jednoduché? No, ono to totiž je jednoduché.

Posledním úkonem, který bude potřeba udělat je vytvořit šablony kone/edit.phtml a kone/create.phtml, ve kterých vypíšeme vlastnost $this->form. Taková šablona může vypadat například takto:

<h2>Nový kůň</h2>
<?= $this->form ?>

No a je to! Nyní zbývá už jen vytvořit si index akci a její šablonu, která bývá většinou specifická a proto jsem se rozhodl ji do controlleru nezařadit. Avšak její implementaci controller požaduje a defaultně do ní přesměrovává své akce.

public function indexAction()
{
        $koneTable = new Kone();
        $select = $koneTable->select()->order(array('jmeno'));
        $this->view->kone = $koneTable->fetchAll($select);
}

A šablona…

<h2>Koně</h2>
<?php
foreach ($this->kone as $kun) {
    ?>Výpis koně<?php
}
?>

Vidíte, že skutečně nebylo potřeba velké množství kódu k funkční aplikaci. V budoucnu napíšu o pokročilejších možnostech CRUD controlleru. Každopádně si již teď nechte s chutí ušetřit čas. A ve volným času třeba čtěte moje tweety.

Do červnového vydání magazínu PHP Architect napsal Ivo Jansch článek o deploymentu aplikace, kde byly popsány i možnosti nasazování aktualizací databáze. Jansch popsal následujících pět úrovní zralosti úpravy databáze při aktualizaci aplikace.

1. Změny jsou prováděn ručně.
2. Během vývoje se změny ukládají v podobě SQL příkazů. Z nich aktualizace vytváří vývojáři ručně.
3. Při aktualizaci se vytvoří seznam „undo“ SQL příkazů, které umožní vrátit databázi do stavu před aktualizací.
4. Existuje nástroj pro automatický výběr SQL příkazů ze souborů vytvořených dle 2. úrovně.
5. Při nasazení se produkční databáze automaticky aktualizuje pomocí porovnání s vývojovou.

Stav naší firmy v minulém článku byl na úrovni 2. A jak jsem se snažil ukázat, tento stav nebyl zcela optimální.

Při posuzování stavu, do kterého bychom se rádi dostali, jsme postupovali od nejvyšší úrovně. Vývojáři nemívají problémy se zaznamenáváním SQL příkazů, takže i 3. a 4. úroveň je přijatelná.

Na základě tohoto rozhodnutí jsme se sestavili následující požadavky na výsledné řešení:

1. SQL příkazy budou ukládány ve stejném repozitory verzovacího systému jako zdrojové kódy aplikace
2. Musí být zaznamenána informace, které soubory již byly na určité databázi provedeny
3. Možnost automatického provedení příkazů, které v určité databázi ještě provedeny nebyly
4. Řešení by mělo dokázat vytvářet „undo“ příkazy

Poslední otázkou bylo, zda se bude nástroj pro aktualizaci databáze vyvíjet nebo se podaří najít odpovídající řešení. Odpověď se dozvíte v příštím článku.

1. Při vývoji je potřeba, aby měli vývojáři vždy k dispozici nejnovější verzi databáze. 2.Během nasazování na produkční prostředí je třeba stávající databázi aktualizovat na novou verzi.

Ve firmě, kde pracuji, jsme při vývoji několika větších projektů řešili tento problém dvěma způsoby.

1. Pro každou novou verzi aplikace byl vytvořen soubor, do kterého se ukládaly SQL příkazy měnící předchozí stav databáze. Soubor byl verzován stejným způsobem jako zdrojové kódy aplikace. Při nasazení nové verze aplikace se provedly všechny SQL příkazy, které soubor obsahoval.
2. Ke každé změně aplikace (přidání nové funkce, oprava chyby…) byl vytvořen soubor obsahující potřebené SQL dotazy. Ten se také ukládal ve stejném úložišti jako zdrojové kódy.Při nasazení nové verze byli zavolány SQL příkazy ze všech souborů, které se od posledního nasazení změnily.

Obě řešení tak nějak fungovali. Jenže pouze tak nějak.

U prvního řešení se naráželo na problém s akutalizací stavu databáze na vývojových prostředí jednotlivých vývojářů. Při aktualizaci stavu souboru s SQL příkazy vývojář vždy musel ručně najít na konci souboru příkazy, které na jeho vývojové databázi ještě nebyly provedeny. Ano, není to zase tak obtížný úkon. Je to však právě tak nesnadný úkon, aby se vývojář ve slabé chvíli rozhodl, že databázi aktualizuje až příště a tím pádem začal pracovat se starou verzí databáze.

Druhé řešení, které původně mělo tento nedostatek odstranit nakonec bylo ještě horší. Vývojáři začali rychle ztrácet přehled, který soubor příkazů již do své vývojové databáze zanesli. Nesnadnost toho rozhodnutí způsobila, že praktický v žádný okamžik několika měsíčního vývoje ani jeden vývojář nepracoval se zcela aktuální verzí databáze.

Jistě si domyslíte, když jeden vývojář odevzdává práci vytvořenou na starší verzi databáze než jeho kolega, který na projektu pracuje také, mohou v projektu vzniknout chyby. A to evidentně zbytečné chyby.

Druhé řešení se navíc ukázalo jako neefektivní i během nasazování nové verze aplikace. Vývojář, který nasazoval novou verzi, musel ručně projít soubory SQL příkazů a provozní databázi a zavolat příkazy pouze z těch souborů, které ještě zaznamenány nebyly. Taková práce vývojáři pak zabrala často celý den. A opět zcela zbytečně.

Jak jsme tento problém řešili dál, napíšu příště. A jak to řešíte u vás?

Takže jsem tu: I LIKE PHP :)

Píšu webové aplikace a intranetová řešení. Píšu je v PHP a je to dobrý. Za ta léta vývoje jsem došel k určitým pracovním postupům a znalostem. A o některých z nich vám rád poutavě napíšu.

Rád píšu i javascriptové frontendy, takže se možná zmíním i o jiných technologiích než je PHP.

Tož se těšte… Hurá!