V příspěvku věnovaném vícevrstvé architektuře bylo uvedeno, že komunikace mezi vrstvami by měla být omezena na minimum a proto je vhodnější používat chunky interface místo chatty.

Jaký je však mezi těmito dvěma interfacy rozdíl? Pro chatty interface (doslova ukecaný interface) je typické, že dochází k přenášení velkého množství zpráv o malé velikosti mezi vrstvami. Je tak náročnější na čas a na zdroje. Chunky interface je naopak navržen tak, aby komunikace mezi vrstvami byla minimální, to ale znamená, že je nutné přenést najednou větší objem dat. Nelze říci, že chatty interface je vyloženě špatný a chunky dobrý. Vždy jde o konkrétní případ, v jakém bude ten či onen interface nasazen.

V minulém díle jsme si popsali jednotlivé vrstvy vícevrstvé architektury, nyní je na čase se zamyslet nad výhodami a nevýhodami vícevrstvé architektury vůbec.

Výhody vícevrstvé architektury

Důsledné oddělení jednotlivých vrstev a volné vazby mezi vrstvami přináší mnoho výhod.  Především, že kterákoliv vrstva může být vyměněna nebo upravena, aniž by to mělo vliv na funkčnost aplikace jako celku.

V příspěvku „Vícevrstvá architektura: popis vrstev“ jsme si stručně charakterizovali jednotlivé vrstvy vícevrstvé architektury, nyní si popíšeme jednotlivé typy SW klientů a jejich výhody a nevýhody.

Tlustý klient (thick client)

Tlustý klient v sobě obvykle obsahuje jak presentační tak i aplikační vrstvu a připojuje se přímo k databázovému nebo jinému serveru. Další typickou vlastností tlustého klienta je, že si přes síť stahuje velký objem dat, která zpracuje a výsledek pak přenese zpět na server.

Vícevrstvá architektura se často označuje jako multi-tier nebo ještě častěji jako n-tier, kde n vyjadřuje počet vrstev, ze kterých se vícevrstvá architektura skládá.

Jako vícevrstvá se označuje proto, že funkčnost aplikace je rozdělena mezi několik vzájemně spolupracujících vrstev, které spolu komunikují přes definované rozhraní. Nejběžnějším příkladem vícevrstvé architektury je architektura třívrstvá, kterou používá mnoho webových aplikací. V takovém případě rozlišujeme vrstvu, která se stará o uživatelské rozhraní, vlastní logiku aplikace a databázi.

Pokud máte funkční aplikaci a uživatelé jsou s ní spokojeni, tak všechny požadavky na nové vlastnosti zamítejte a nové vlastnosti nepřidávejte. Proč?

Protože aplikace by měla obsahovat jen ty vlastnosti, které jsou opravdu potřeba. Zaměřte se spíš na to, aby vám ty stávající vlastnosti fungovaly naprosto perfektně a obsluha vaší aplikace byla co nejjednodušší a nejintuitivnější. Jestliže musí uživatel absolvovat školení nebo číst nějaký manuál, aby vůbec mohl začít s vaší aplikací pracovat, znamená to, že někde je něco špatně.

Cílem tohoto příspěvku je upozornit na rizika vyplývající z používání spreadsheetů a poskytnout návod jak tato rizika minimalizovat.

Už jste někdy učinili rozhodnutí na základě informací uvedených ve spreadsheetu? Ať už jste na tuto otázku odpověděli kladně nebo záporně, měli byste si přečíst tento článek. Problém je v tom, že zatímco původní data jsou pořizována, zpracovávána a uchovávána v relativně bezpečných systémech, tak poté jsou exportována do velice zranitelných spreadsheetů, ve kterých lze velice obtížně zajistit požadovanou integritu. A je jedno, zda se jedná o spreadsheet vytvořený v produktu OpenOffice.org Calc nebo MS Excel.