Vlákno názorů k článku Cibulová architektura aneb jak nepřipravovat špagety od SmallM - Podle našich dlouholetých zkušeností je u klasických webových...

Podle našich dlouholetých zkušeností je u klasických webových víceuživatelských aplikací základem správně navržená databáze. Databáze umožní definovat vztahy mezi objekty, pravidla pro hodnoty atributů, i pohledy na data. Navíc je v jistém smyslu "univerzální" z pohledu technologického vývoje. Správná aplikace je pak jen datově řízená záležitost nad správně postavenou databází. Většinou totiž samotná aplikace je jen způsob, jak se k datům dostat.
I pro ostatní naprosto odlišné aplikace (např. grafický editor, počítačová hra) je klíčový moment způsob ukládání dat (konvence) a práce s nimi. Když si vezmete např. počítačovou hru, ta se opírá o možnosti nějakého herního enginu - a v konečném důsledku opět skončíte u způsobu, jakým se ukládají data a jakými metodami se s takto uloženými daty následně ve vytvořeném systému pracuje.

24. 1. 2020, 09:17 editováno autorem komentáře

Dobrý den,

Tímto přístupem jste výkonostně, návrhově i technologicky velmi závislí na třetí straně jako například na Microsoft SQL Serveru. V posledních letech příchází do módy NoSQL dokumentové databáze. Jakým způsobem byste řešili přechod na jinou, modernější technologii?
Obávám se, že takové webové aplikace mají kratší životnost, než by mohly být.

U každého většího řešení budete vždycky závislý na nějaké třetí straně . Kdo říká že ne, tak nemluví pravdu. Technologie přicházejí a odcházejí, ale principy rozumného návrhu platí obecně.
Mimochodem Vámi uvedené příklady nepoužíváme, ale jádra problému se to netýká. Pokud nebudete mít rozmyšleno, co jsou data a jak s nimi budete pracovat, ja tvorba aplikace -nebo její výměna- zbytečná. Také to, zda použiji nonSQL nebo SQL (pracujeme s obojím), je vedlejší.

„U každého většího řešení budete vždycky závislý na nějaké třetí straně . Kdo říká že ne, tak nemluví pravdu.“
To nikdo nepopírá, ale je nutno si vybrat tak, aby jádro aplikace bylo v nejméně závislých technologiích s nejmenšími změnami. Je rozdíl napsat dom. model v specializovaném jazyku specializované DB, nebo použít obecný programovací jazyk, na který existuje několik IDE či překladačů a bude tady ještě za 30 let.

Dobrá, souhlasím, že sem použil nešťastný výraz. Móda na to opravdu nemá vliv. Ovšem nové databázové přístupy vznikají z nějakého důvodu. Vezměte si Elastic Search. Je to mnohem vhodnější nástroj pro fulltextové vyhledávání než relační databáze. ElasticSearch je mladý a odhaduji že před deseti lety zde nebyl. Můžeme poskytnout větší výkon aplikace, ale je ho nemožné do Vaší aplikace zakomponovat nebo je to velmi náročné a zákazník to nebude chtít zaplatit. Tím pádem aplikace "hnije"

Ale pořád budu mít daleko raději kvalitní fulltext rovnou v DB, než řešit synchronizaci dat do neprimárního ES. Bohužel kvalitních fulltextů v DB je minimum, tak nezbývá než vytvářet funkcionalitu extra pro fulltext v ES.

Když máte aplikaci s volnými závislostmi, můžete si dovolit používat a nabízet i módu.

„V posledních letech příchází do módy NoSQL dokumentové databáze. Jakým způsobem byste řešili přechod na jinou, modernější technologii?“
No jak by to řešil? Nijak, znamenalo by to všechnu obchodní logiku přepsat do nového typu DB, což samo o sobě ještě neřeší komunikaci aplikace s novou DB.

„Podle našich dlouholetých zkušeností...“
Éééé...
„...je u klasických webových víceuživatelských aplikací...“
Web je jen formou prezentace, u aplikací s jinými či více graf. rozhraními to neplatí???
„...základem správně navržená databáze.“
A je to tady - databázocentrická aplikace!
„Databáze umožní definovat vztahy mezi objekty, pravidla pro hodnoty atributů, i pohledy na data.“
To patří do doménového modelu, ne persistentní vrstvy.
„Navíc je v jistém smyslu "univerzální" z pohledu technologického vývoje.“
Bohužel není, každá DB má trochu jiné vlastnosti, v případě rozdílných typů hodně jiné vlastnosti.

Databáze je vrstvou (dle cibule částí), která se bude jistě měnit mnohem častěji než jazyk, ve kterém je napsaný dom. model, tudíž není strategické do ní umisťovat obchodní logiku. Dále: Co uděláte, když nebudete mít data uložena jen v oné jedné jediné DB, ale třeba ve 3 zcela různých? A nebo v nějakém úložišti přes HTTP? Kde bude potom umístěn dom. model s logikou? Jak bude komunikovat se zbytkem?

Taky jsem dělal v jedné velké, české, nejmenované firmě, kde bylo vše zadrátováno v DB, a to rovnou ve 3 typech RDB (to k té vaší „univerzálnosti“). Muselo se to dělat 3x, testovat se to pořádně nedalo, bylo to chybové a ukrutně pracné. O existenci dokumentových, objektových, sloupcových, časových a jiných typech DB vedení ani vývojáři netušili. Když se řešila nějaká nová vlastnost, nikdy se neřeklo „to přijde do dom. modelu sem a sem“, první bylo „do té a té tabulky dáme tenhle a tenhle sloupec“. Od konce.
Jako bonus bylo SQL v některých místech prorostlé až do prezentační vrstvy. Jakákoliv změna GUI či DB by znamenala roky úprav, což bylo nereálné, takže SW buďto nechat zabetonovaný, nebo začít úplně znovu. A to se vyplatí!