UNICORN COLLEGE. Bakalářská práce

Transkript

1 UNICORN COLLEGE Katedra informačních technologií Bakalářská práce Realizace modulárního CMS pro digitální agentury Autor BP: Jan Branný Vedoucí práce BP: Ing. David Hartman, Ph.D 2018 Praha

2

3

4 Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma Realizace modulárního CMS pro digitální agentury vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil/a autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení 11 a následujících autorského zákona č. 121/2000 Sb. V dne Jan Branný

5 Poděkování Děkuji Ing. Pavlu Borymu. za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.

6 Realizace modulárního CMS pro digitální agentury Implementation of Modular CMS for Digital Agencies 6

7 Abstrakt Práce pojednává o vhodných principech, jak vyvíjet moderní webové aplikace pomocí technologie ASP.NET Core. Vše je demonstrováno na ukázce vývoje modulárního webového systému pro správu obsahu. Klíčová slova: MS Azure, SPA, Angular, WEB Abstract The bachelor s thesis deals with the appropriate principles of how to develop modern web applications using ASP.NET Core. Everything is demonstrated to demonstrate the development of a modular web content management system. Keywords: MS Azure, SPA, Angular, WEB 7

8 Obsah Úvod Cíl práce Systém pro správu obsahu V současnosti dostupné CMS vytvořené pomocí ASP.NET Core ASP.NET Core Charakteristiky moderní ASP.NET Core aplikace Model-View-Controller Angular Přehled architektury Dependency Injection Životnosti služby Entity Framework Core Základní pojmy Objektově relační mapování (ORM) Databázoví poskytovatelé Správa Entity Frameworku Hostování web aplikací na Microsoft Azure Azure app service Azure SQL Database Azure DocumentDB Popis aplikace Příprava prostředí Architektura systému N-layer pohled Pohled na moduly Distribuce a připojení modulu Rozšíření dotnet tools

9 9.5 Klientská část Angular Možnosti rozšíření Závěr Conclusion Seznam použitých zdrojů Seznam obrázků Seznam tabulek Seznam příloh

10 Seznam pojmů a zkratek Tabulka 1 seznam pojmů a zkratek Zkratka Význam Popis CMS Content Management System Systém pro správu obsahu WYSIWYG What You See Is What You Get Editor pro práci s HTML.NET Framework Softwarový framework vyvinutý společností Microsoft primárně na vývoj aplikací pro Windows ASP.NET Framework Nadstavba.NET Frameworku pro tvorbu webových aplikací a služeb MVC Model-View-Controller Architektura MVC C# C Sharp Objekotvě orientovaný jazyk z rodiny.net WPF Windows Presentatio Foundation Knihovna pro tvorbu grafického rozhraní pro desktopové aplikace.net Framework UWP Universal Windows Apps Technologie pro psaní univerzálních aplikací AJAX Asynchronous JavaScript and MXL Technologie vývoje interaktivní webových aplikací EF Entity Framework Framework pro objektově relační mapování ORM Object-relational mapping Objektově relační mapování IIS Internet Information Service Webový server CLI Command-Line Interface Prostředí pro psaní příkazů LINQ Language Integrated Query Dotazovací jazyk pro.net SQL Structured Query Language Dotazovací jazyk pro práci s relačními databázemi SEO Search engine optimalization Optimalizace pro internetové vyhledávače SPA Single Page Application Jednostránková aplikace 10

11 Úvod Jedním z problémů se kterým se dnes potýká skoro každá menší a středně velká digitální agentura zaměřující se především na tvorbu microsite nebo prezentačních webových stránek je absence snadného vytvoření systému, pomocí něhož by bylo možné snadno spravovat obsah webové stránky a zároveň mít pod kontrolou editovatelné prvky, aby nedocházelo ke vkládaní nevalidních dat. Vzhledem k tomu že každý prezentační web nebo microsite se znatelně liší svými požadavky, je velmi náročné mít univerzální řešení, které by pokrylo všechny tyto požadavky různých webových stránek. Nezbývá tak nic jiného než pro každou internetovou stránku vytvářet vlastní administraci, což značně navyšuje časovou náročnost a cenu, kterou zákazník bude muset zaplatit. Často se tak systém pro správu nevytváří a všechna data jsou napsána přímo v šabloně prezentace. Problém, který tím vzniká, je značná redundance opakujícího se kódu. V případě změn je tak potřeba upravovat stejný kód na více místech, tím se zvyšuje časová náročnost na správu a úpravu webových stránek a zároveň se také zvyšuje riziko chybovosti. Pro digitální agentury by bylo velikým přínosem mít k dispozici nástroj, pomocí něhož by si mohly snadno definovat, jak má administrační prostředí pro správu obsahu vypadat. A věnovat se tak především tvorbě webové prezentace, která je pro zákazníka tím nejdůležitějším ukazatelem kvality. Administrační systém pro správu obsahu je tak dobrou přidanou hodnotou, kterou ocení ji jak zákazník, tak i digitální agentura. Na trhu dnes můžeme najít spoustu systémů řešících tento problém, ale bývají zaměřeny pouze na jeden konkrétní typ internetové stránky jako je například blog, nebo e-shop. Je složité pak vytvořit kombinaci, nebo rozšíření blogu, aby obsahoval například mini e-shop. 11

12 Cíl práce Cílem této práce je navrhnout projekt modulárního webového systému pro správu obsahu, který bude sloužit jako nástroj pro vývojáře k rychlému vytvoření a nasazení administrace webové aplikace. V první části aplikace jsou popsány základní technologie, pomocí nichž se projekt řeší, a následně je popsána implementace některých pro systém klíčových řešení. 1 Systém pro správu obsahu Systémy pro správu obsahu jsou dnes již standardním prvkem, který má každá moderní internetová stránka. Dnešní internetové stránky se většinou neskládají jen ze statického HTML soboru, ale jsou generovány na serveru a upravují svůj obsah podle získaných dat. Správci těchto stránek tak potřebují mít k dispozici snadný způsob, jak tato data do stránek přidávat a upravovat. Za tímto účelem se začaly vyvíjet systémy pro správu obsahu. Na trhu se sice nachází již spousta osvědčených a spolehlivých systémů pro správu obsahu, převážná část z nich je ale psaná pomocí jazyka PHP nebo na starší verzi ASP.NET. Systémy vytvořené v ASP.NET většinou bývají velmi drahé a nejsou proto vhodné pro menší projekty. Nevýhodou většiny dostupných systémů také bývá to, že jsou vytvořeny za jedním konkrétním účelem, jako např. E-shop, nebo blog. Jejich následné rozšiřování či kombinace bývá velmi problematická a vyžaduje dobrou znalost daného systému. Velké množství dnes populárních systémů lze rozšiřovat pomocí pluginů, které je možné si vytvořit nebo si je stáhnout z poskytovaných galerií. Pluginy můžeme do stránky přidávat za běhu. Tento přístup má výhodu, že stránky lze upravovat bez přerušení provozu. To však tento přístup často přináší spoustu nevýhod, jako například nevýhodu v podobě testování, které je tak poměrně náročné. A mnohdy s tím přináší také i nekompatibilita jednotlivých pluginů. 12

13 1.1 V současnosti dostupné CMS vytvořené pomocí ASP.NET Core OrchadCore CMS OrchadCore CMS je bezplatný modulární Systém pro správu obsahu vytvořený a spravovaný komunitou vývojářů z.net FOUDNATION. Jedná se o re-implementaci populárního Orchad CMS, který byl vytvořen na klasické verzi ASP.NET MVC 5. Současně se projekt nachází ve stavu beta testování a verze RC je plánovaná na jaro ASP.NET Boilerplate ASP.NET Boilerplate je univerzální aplikační framework určený pro tvorbu nových moderních webových aplikací. Využívá již známé nástroje a přináší vývojářům řadu osvědčených postupů, které jim poskytují prostředí pro vývoj stabilních webových aplikací. ASP.NET Boilerplate poskytuje infrastrukturu pro vytváření modulárních aplikací. Architektura také umožňuje přidávat moduly, které jsou závislé na ostatních modulech. Klientská část je řešena jako SPA pomocí webové technologie Angular 2. APB také nabízí rozšířenou placenou variantu. Platformus Platforumus je komplexní a víceúčelový systém pro správu obsahu, který je vhodný především pro vývojáře. Platformus je velmi flexibilní, a proto lze všechny jeho části změnit nebo nahradit. Základní verze v sobě implementuje možnosti pro tvorbu vícejazyčných a multikulturních aplikací. 2 ASP.NET Core ASP.NET Core je multiplatformní, vysoce výkonný open source framework pro vytváření moderních cloudových a webových aplikací. V současnosti se nachází ve verzi 2.0 a nabízí spoustu rozšíření ke stažení zdarma Vývoj ASP.NET Core aplikací je možný buďto pomocí standartního.net Frameworku 4.6, který nabízí plnou integraci všech.net knihoven a běhového prostředí pro operační systém Microsoft Windows..NET Framework se využívá především pro tvorbu desktopových aplikací jako je WPF nebo Windows form Odlehčené verze.net Core nabízí optimalizované a modulární.net knihovny, a prostředí, které je možné spouštět na všech platformách jako Windows, Apple OS nebo 13

14 operační systémy na bázi Linuxu. Verze.NET Core je především vhodná pro tvorbu moderních webových aplikací nebo Universal Windows Apps. Velkou výhodou oproti předchozí verzi ASP.NET je, že aplikace je schopna hostovat sama sebe ve vlastním procesu.net Execution Environment (DNX), bez závislosti na IIS. Aplikaci je tak možné bez větších problémů přenášet na jiné hostingové prostředí. To přináší hlavně výhody v oblasti cloudových služeb. Veškeré projekty, jak celé aplikace, tak knihovny, je nyní také možné sestavit a sémanticky verzovat do NuGet balíčků a následně je také jejich prostřednictvím šířit. ASP.NET Core je celý složen z NuGet balíčků. To umožňuje aplikaci používat jen ty části, které opravdu potřebuje. Díky tomu je aplikace značně menší, bezpečnější a rychlejší [1] 2.1 Charakteristiky moderní ASP.NET Core aplikace Cloud a škálovatelnost ASP.NET core je optimalizovaný pro vývoj cloudových aplikací, protože má velmi nízké nároky na využití paměti a velkou datovou propustnost. Aplikace lze díky své nízké náročnosti snadno optimalizovat pro hostování v cloudovém prostředí. [2] Multi platformost ASP.NET core je multiplatformní a je možné jej vyvíjet a spouštět na operačních systémech jako je Linux, MacOS nebo Windows. Je tak možné vyvíjet na více platformách současně a neomezovat se pouze na jeden typ operačního systému. ASP.NET core je také možné používat společně s technologií docker a využít tak veškeré výhody jako jsou kontejnery nebo mikro služby. Vytvořené aplikace je pak možné hostovat na jakémkoli operačním systému, nebo cloudovém řešení. [2] Modularita.NET Core se celý skládá z modulů. Veškeré moduly jsou distribuované jako knihovny pomocí NuGet balíčků. Díky tomu lze zajistit, že aplikace jsou závislé pouze na funkčnostech, které opravdu potřebují. Což snižuje jejich velikost a bezpečnostní rizika. ASP.NET Core také plně podporuje Dependency Injection. Můžeme tak pracovat pouze s rozhraním a měnit jednotlivé služby dle potřeby. [2] 14

15 Testování ASP.NET aplikace podporují testování pomocí unit testů. Díky Dependency injection není problém jednotlivé části infrastruktury vyměnit za falešné moduly pro testovací účely. ASP.NET Core také nabízí vlastní Test server, který umožňuje hostovat celé aplikace v paměti a tím značně urychlit testování. [2] Vývoj klientské části ASP.NET Core nabízí standardní tvorbu uživatelského rozhraní pomocí Razor pages, ale je navrhnut tak, aby byl snadno použitelný s velkou škálou klientských frameworku jako jsou například SPA frameworky Angular 2 nebo React. Dnešní moderní aplikace se již neskládají pouze z požadavků na server, ale nabízí i provádění některých operací v klientském prohlížeči. Jedním z příkladů může být posílání požadavků pomocí AJAX a překreslování jen části stránky, což, ale není úplně vhodné při dodržování solidní architektury systému. ASP.NET Core aplikace je velmi snadné vytvářet společně s Single-Page Aplikačními Frameworky a dramaticky tak snížit požadavky kladené na server, protože velká část operací může být právě prováděna v klientských prohlížečích a zároveň lze uživateli nabídnout příjemnější uživatelské prostředí a plynulejší práci s aplikací. [2] Snadný vývoj a nasazení ASP.NET Core aplikace je možné vytvářet pomocí klasických textových editorů a příkazového řádku, nebo pomocí profesionálních vývojářských nástrojů jako je Visual Studio 2015 a novější. Klasické webové aplikace jsou většinou nasazovány na jeden server. Nasazení tak může probíhat automaticky pomocí tzv. Continous Integration & Continous Delivery. [2] 15

16 2.2 Model-View-Controller ASP.NET Core je založen na velmi populárním architektonickém vzoru MVC. Jedná se o softwarovou architekturu, která rozděluje aplikaci na datový model a aplikační logiku (Model), uživatelské rozhraní (View) a řídící logiku (Controller) Funkce architektury ASP.NET MVC Obrázek 1 Architektura MVC [13] Oddělení aplikačních úloh (logika vstupu, obchodní logika a logika uživatelského rozhraní), testovatelnost a testy řízený vývoj (TDD). Všechny základní kontrakty architektury MVC jsou založeny na rozhraní a lze je testovat pomocí mock objektů, což jsou simulované objekty, které napodobují chování skutečných objektů v aplikaci. Můžete testovat aplikaci po jednotkách bez nutnosti spouštět kontrolery v procesu ASP.NET, takže je testování jednotek rychlé a flexibilní. Můžete použít jakékoli prostředí testování jednotek, které je kompatibilní s rozhraním.net Framework. Rozšiřitelná a modulární architektura. Komponenty architektury ASP.NET MVC jsou navrženy tak, aby je bylo možné snadno nahradit a přizpůsobit. Můžete zařadit vlastní zobrazovací modul, zásady směrování adres URL, serializaci parametrů metody akce a další komponenty. Architektura ASP.NET MVC dále podporuje použití modelů kontejnerů DI (Dependency Injection) a IOC (Inversion of Control). Technologie DI umožňuje injektovat objekty do tříd, namísto spoléhání na 16

17 třídu, že objekt vytvoří sama. Technologie IOC určuje, že když objekt vyžaduje jiný objekt, první objekt by měl získat druhý objekt z vnějšího zdroje, jako je konfigurační soubor. Tím je testování jednodušší. Extenzivní podpora směrování ASP.NET, což je účinná komponenta mapování adres URL, umožňuje sestavit aplikace, které mají srozumitelné a dohledatelné adresy URL. Adresy URL nemusí obsahovat přípony souborů a jsou navrženy tak, aby podporovaly vzory mapování adres URL, které jsou vhodné k optimalizace pro vyhledávací weby (SEO) a adresování REST (representational state transfer). Podpora stávajících funkcí ASP.NET. Architektura ASP.NET MVC umožňuje využívat funkce, jako je ověřování pomocí formulářů a ověřování systému Windows, autorizace adres URL, členství a role, ukládání dat a výstupu do mezipaměti, správa stavů relací a profilů, sledování stavu, konfigurace systému a architektura zprostředkovatele. [3] Model Model je ta část architektury, která uchovává veškerou aplikační logiku, služby, datový model a přístup k nim. Bývá často rozdělen na více podvrstev podle návrhové vzoru N- Layer. Toto rozdělení, také umožňuje využívat principů Domain Driven Design Datová vrstva Doménová vrstva Aplikační vrstva Obrázek 2 N-Layer (Onion-View) (vlastní zpracování) [2] 17

18 Datová vrstva Datová vrstva se skládá ze služeb pro přístup k datům a O/RM frameworku. Jedná se o vrstvu, která se především stará o přístup a správu perzistentních dat. Výstupem této vrstvy by měl být Repositář, který zapouzdřuje služby pro přístup k datům. Díky tomu je tak následně možné přejít na jiný datový zdroj, aniž by došlo k ovlivnění funkcí zbytku aplikace. Datová vrstva se nám také stará o validaci objektů, zajišťuje transakce a modifikuje data podle zvoleného formátu. Doménová vrstva Na doménové vrstvě je definován doménový model, doménové služby a různé podpůrné služby. Doménový model je definicí objektů, se kterými aplikace pracuje. Jedná se o třídy, které mapují data z uložiště. Většinou je zapouzdřujeme pomocí ORM, které se nám postará o jejich převedení do modelu pro perzistentní uložiště. Doménové služby Jedná se o služby, které nám zajišťují jednotlivé operace s datovým modelem, jako je například CRUD (Create, Read, Update, Delete), ale i modifikace dat a konkrétní případy užití entity. Podpůrné služby Jsou to služby například pro logování událostí, cache výsledků, konfigurace apod. Aplikační vrstva Aplikační vrstva se skládá z veškerých služeb, která naše aplikace poskytuje. Jedná se o spojení doménových služeb do logických bloků. Výstupem je tak již konkrétní služba, která řeší specifický problém například: vymaž všechny uživatele kteří se nepřihlásili déle než rok a odešli jim upozornění Pohled (View) Pohled slouží k zobrazování výsledků uživateli. Uživatel jeho prostřednictvím vidí data v čitelné podobě a může s jeho pomocí volat jednotlivé akce kontrolérů. Při vytváření aplikace pomocí ASP.NET se pohled skládá z Razor pages (veškeré HTML jsou generovány na straně serveru). Nebo se může jedna o dnes velmi populární SPA (Single-page applicaiton) vytvořené z dostupných frameworků, jako je například Angular nebo React. 18

19 2.2.4 Kontrolér (Controller) Kontrolér je prostředník, který nám zajišťuje veškerou komunikaci mezi pohledem a modelem. Kontrolér v podstatě jen příjme požadavky a převádí data od uživatele prostřednictvím pohledu. Na základně požadavku aplikační vrstva provede zpracování a kontrolér následně vrátí výsledek zpátky do pohledu a zobrazí jej uživateli. Na úrovni kontrolérů, také probíhá základní ověření, jestli uživatel pro danou operaci má oprávnění. 3 Angular 2 Angular je aplikační platforma pro vytváření klientských aplikací pomocí značkovacího jazyka HTML a programovacího jazyka TypeScript. Oproti předchozí verzi (AngularJs) je celá platforma napsaná právě pomocí jazyka TypeScript a využívá tak plný potenciál, který tento jazyk nabízí. Velkou výhodou použití Angular 2 je možnost využívání HTML šablon. Angular nabízí možnosti pro sledování vyvolaných událostí uživatelem a také předávání vlastností mezi komponentou a šablonou v obou směrech. Je tak snadné měnit hodnoty přímo v šabloně. 19

20 3.1 Přehled architektury NgModule Obrázek 3 Angular 2 architektúra [16] Základní součástí aplikace vytvářené pomocí Angularu jsou NgModules, které poskytují kompilační kontext pro komponenty. NgModules obsahuje informace o požadovaných komponentách a službách, které aplikace vyžaduje. Každá aplikace musí obsahovat takzvaný root module, který se stará o vytvoření a spuštění aplikace. Vzhledem k tomu že je Angular plně modulární, tak se aplikace typicky skládají z více modulů. Aplikace je tak díky tomu snadno spravovatelná a je možné jednotlivé moduly snadno přenášet na jiné projekty. NgModule je deklarační funkce, která převezme metada obejktu, který popisuje module. Metadata modulu jsou následující. declaration třídy komponenty, direktivy, pipes se kterými modul pracuje exports třídy, které module poskytuje navenek a mohou je používat ostatní moduly, který tento modul importují imports moduly, které modul používá. Importuje všechny třídy, který daný modul exportuje. providers služby modulu, které se registrují do dependency injection kontejneru a je možné k nim následně přistupovat. bootstrap hlavní komponenta neboli root komponenta, která se slouží jako vstupní bod aplikace 20

21 V angularu existují dva hlavní moduly BrowserModule a CommonModule BrowserModule - musí být importován hlavním modulem. CommonModule je importován ostatními moduly Komponenty Komponenta je třída, která slouží jako řadič pro šablonu. Zajišťuje veškerou komunikaci mezi aplikací a HTML šablonou. Komponenty, které chceme v aplikaci používat musí být nejprve registrovány v některém z modulů. Metadata komponent To že se jedná o komponentu angular pozná pomocí metadata informací registrované pomocí dekoratérů Dekoratér definuje mnoho informací, pomocí kterých je možné upravovat vlastnosti komponent. Mezi ty nejdůležitější, které musí definovat každá komponenta patří. 1 selector selektor pomocí, kterého můžeme vytvořit komponentu v HTML šabloně. Template(Url) odkaz na HTML šablonu, nebo napsaná šablona přímo v metamodelu komponenty. Data binding Data binding je důležitou součástí každé alngular aplikace. Jendá se o způsob jakým můžeme předávat informace mezi šablonou a komponentou. Angular nám nabízí dvě základní techniky. One-Way a Two-Way data binding. První možností pro předávání dat je One-Way data binding který předává informace pouze v jednom směru. Předání informací do šablony můžeme buď pomocí {{VLASTNOST}} a tím zobrazíme požadovanou hodnotu v šabloně. Nebo předávání do vlastností HTML elementů [property]= VLASTNOST Pokud chceme předávat informace ze šablony do komponenty můžeme tak pomocí událostí (event)= handler a tím vyvolat akci komponenty. Druhou možností je použití Two-way data binding, který předává změny o hodnotě ať už byly vyvolány na straně komponenty nebo šablony. Two-way data binding můžeme 1 Kompletní výčet všech informací lze nalézt v dokumentaci na adrese 21

22 použít pomocí [(ng-model)]= VLASTNOST. Angular se postará o vytvoření potřebných funkcí pro zajištění komunikace. Obrázek 4 Data binding v Angular 2 [16] Životní cyklus komponenty Po zavolání konstruktoru komponenty komponenta prochází svým životním cyklem. Životní cyklus je důležitou součástí každé komponenty. Můžeme v něm sledovat změny a vyvolávat události, které chceme při dané akci provést Služby Služba je široká kategorie zahrnující libovolnou hodnotu, funkci nebo vlastnost, kterou aplikace potřebuje. Služba je obvykle třída s úzkým, dobře definovaným účelem. Služba by vždy měla řešit jeden konkrétní účel. [4] Angular rozlišuje komponenty od služeb kvůli zlepšení modularity a znovu použitelnosti služeb ve více komponentách. Oddělením aplikační logiky od komponent vznikají čistější a efektivnější komponenty. Hlavním cílem komponent by měla být jen komunikace s klientem a nic více. Komponenta by měla pouze prezentovat výsledky provádět validace uživatelského vstupu, a logovat informace přímo do konzole. Například komunikace se serverem by měla vždy probíhat pomocí služeb a být tak znovu použitelná ve více komponentách. 2 Kompletní životní cyklus komponenty lze nalézt na adrese [2018] 22

23 Dependency Injection Veškeré služby, které se v angularu používají by měly být předávány pomocí dependency injection a registrovány v komponentách pomocí jejich konstruktoru. Služby které mají být registrovány v dependency injeciton kontejneru musí být označeny a deklarovány v modulu. Dependency injection je součástí Angualru a není potřeba implementovat dodatečné knihovny, které by zajišťovaly potřebnou funkcionalitu. V komponentě máme možnost určit, jestli předaná služba má být typu singleton, nebo jestli komponenta vyžaduje novou instanci typu transient. [4] 4 Dependency Injection Dependency injection (DI), neboli předávání závislostí je technika pro předávání služeb mezi jednotlivými komponentami nebo službami aplikace, tak aby komponenty tyto služby mohly využívat, aniž by na ně existovaly statické odkazy. Je tak možné používat stejnou instanci služby ve dvou různých komponentách, aniž bychom museli složitě řešit reference mezi nimi, nebo to, jaká instance má být použita. Nejpoužívanější způsob, jak závislosti předávat je pomocí konstruktoru. V konstruktu nám stačí definovat jaké třídy, nebo rozhraní daná komponenta požaduje a Dependency injection se nám postará o vytvoření instance komponenty a předání požadovaných služeb. Pokud požadované služby v komponentě, definujeme pouze jako její rozhraní, můžeme, tak snadno jednotlivé služby nahradit jinými, které splňují toto rozhraní a jednoduše tak změnit chování aplikace, nebo nahradit službu jinou. Příkladem může být při vývoji použití služby pro logování, která nám bude veškeré informace vypisovat do konzole a na produkčním prostředí použít logovací službu, která informace zapíše do databáze. Jediné, co je pro to potřeba je změnit poskytovatele daného rozhraní. Při definování dependency injection v ASP.NET Core rozlišueme mezi třemi druhy jejich životnosti. 23

24 4.1 Životnosti služby Singleton služby Služby registrované s životností singleton jsou vytvořeny pouze jednou při jejich prvním zavolání, nebo pokud při definici předáme již vytvořenou instanci. Všechny služby nebo komponenty, které následně požádají o tuto službu tak dostanou již vytvořenou instanci a sdílí se ostatními. Živostnost služby v ASP.NET Core přetrvává i po skončení daného požadavku na server. A při dalším není potřeba vytvářet novou instanci, ale pracovat již z existující. Díky tomu je možné uchovávat některé aspekty aplikace v paměti. Služba zaniká až při ukončení aplikace, nebo ručním vynucením. Služby typu singleton používáme v případě, že není potřeba vždy vytvářet novou instanci. Příkladem může být například služba pro logování aplikace, pro kterou nám stačí pouze jediná instance napříč celou aplikací. Transient služby Pro služby registrované s životností transient, je vždy při jejich zavolání vytvořena nová instance. Tudíž každá komponenta nebo jiná služba obsahuje vždy samostatnou instanci a neovlivňuje, tak ostatní. Příkladem může být například registrace generické entity. Služby, které tuto entitu vyžadují se nemusí starat o její vytvoření pomocí generického parametru, ale dependency injeciton se postará o vytvoření nové instance a následné předání službě. Scoped služby Služby registrované s životností scoped, jsou vytvářeny vždy jen po dobu probíhajícího requestu. Můžeme tak vytvářet služby, které jsou potřeba jen pro současnou operaci a neovlivňovat, tak zbytek chodu aplikace. Příkladem může být služba pro přihlášení uživatele. Požadavek potřebujeme zpracovat pouze jednou a není potřeba, aby se daná služba držela v paměti aplikace poté co je uživatel přihlášen. 24

25 5 Entity Framework Core Entity Framework Core je multiplatformní, odlehčená a rozšiřitelná verze populárního Entity frameworku. Ačkoliv Entity Framework core zachovává veškeré známe vývojářské principy ze standartního Entity Frameworku nezměněné, některé jeho základní části byli kompletně přepsány. To znamená, že některé vlastnosti nebyly automaticky zděděny. Některé vlastnosti budou uvedeny až v budoucích verzích např. Lazy loading. A jiné méně populární vlastnosti nebudou implementovány vůbec [5] Entity Framework Core je technologie, která umožňuje mapovat relační databáze na objekty programu. Vývojáři, tak mohou pracovat s databází pomocí.net 5.1 Základní pojmy Entity Data Model Jedním z důležitých pojmů při práci s Entity Frameworkem je Entity Data Model (EDM). Jedná se o základní stavební kámen Entity Frameworku. Entity Data Model je definice objektů, které budou následně ukládány do databáze. Pomocí těchto objektů pak vývojář může přistupovat k datové struktuře aplikace Metada Pro správné vytvoření Entity Data Modelu je potřeba třídám a jejich vlastnostem přiřazovat dodatečné informace. Metadaty rozumíme atributy, které jsou přiřazovány jednotlivým třídám nebo vlastnostem. Jejich účelem je zpřesnit informace jaké má mít sloupec v tabulce vlastnosti. Může se jednat například o informace, že se jedná o primární klíč, maximální a minimální délku textu, jestli je vlastnost povinná, nebo jestli se jedná například o cizí klíč. Pro přiřazování Metadat datovým objektům nám Entity Framework poskytuje dvě možnost, jak informace přidávat. První možností je definovat objekty pomocí Data Annotation atributů, které můžeme přidávat jednotlivým třídám nebo vlastnostem třídy. Tento způsob je velmi oblíbený, protože nabízí velmi přehledně co vše za metadata objekt obsahuje. Data Annotation atributy jsou používané ve více službách a je možné pomocí nich provádět například validace při poslání požadavku s objektem na kontrolér. 25

26 Data Annotation atributy nám bohužel neumožňují definovat všechny potřebné informace, které potřebujeme pro správné nastavení databáze. Je tak často potřeba přidávat ještě informace v podobě EntityTypeConfiguration, jež nabízí fluent api pro definici objektů. Tento způsob dává mnohem více možností, které lze definovat, například pokud má databáze automaticky počítat některé sloupce, lze tak snadno definovat jakým způsobem toho má být docíleno. Nebo lze použít funkce, které databáze poskytuje například funkci Date(), pokud chceme automaticky zaznamenávat informace o změně záznamu v databázi Kontext (context) Kontext je v Entity Frameworku objekt, který nám umožňuje interakci s databází, načítání a ukládání objektů z databáze. Kontext, také udržuje informace o objektech. Tyto objekty jsou vytvořeny jako tzv. proxy třídy, které jsou spojeny s kontextem a uchovají informace o modifikacích dat a jejich následnou synchronizaci. 5.2 Objektově relační mapování (ORM) Entity framework je nástrojem pro objektově relační mapování (ORM). Objektově relační mapování je obor, který řeší rozpor mezi objektově orientovaným programováním a nutností ukládat data pomocí relačních databází. Klasická verze entity frameworku nám umožňovala vytvářet doménové objekty z již vytvořené databáze pomocí nástroje, který je součástí programu Visual Studio. Tato možnost již v nové verzi Entiy Framework Core není a je preferován přístup Code-First. Přístup Code-first je založen na principu, že vývojář nejprve definuje v aplikaci doménový model (EDM) a jejich vlastnosti. Jednotlivým vlastnostem jsou následně přidány meta informace v podobě atributů. Z vytvořených tříd je následně vygenerována struktura databáze. 5.3 Databázoví poskytovatelé Entity framework core nám umožňuje si vybrat z několika poskytovaných databázových řešení. Není tak problém se limitovat pouze na řešení MS SQL, ale zvolit jiné libovolné řešení. Některé funkce jsou, ale limitované v závisti na zvoleném poskytovateli. 26

27 Mezi současné populární poskytovatele dnes patří např. Microsoft SQL Server, SQL Lite, Posgtre SQL, MySQL a InMemory. Pokud má systém dobře navrženou architekturu, není problém databáze v průběhu měnit. To se hodí například při vývoji na více operačních systémech. Operační systémy na bázi Unix například nepodporují Microsoft SQL Server. Proto se často volí jiný poskytovatel, a při spuštění aplikace v prostředí Microsoft Windows je možné aplikaci napojit na plnohodnotný Microsoft SQL Server. Častou volbou během vývoje systému bývá InMemory. Ten je vhodný především ze začátku vývoje aplikace pro snadné testování funkčnosti datového modelu a následné migrace. 5.4 Správa Entity Frameworku Pro práci s entity frameworkem core je možné využívat již známe řešení Package Manger Console integrované přímo v programu VIsual Studio a spouštět požadované scripty z této konzole. Nebo využívat nové řešení.net Core CLI, které je vhodné především při vývoji na jiných platformách, než je Microsoft Windows. Příkazy lze tak možné spouštět přímo z příkazového terminálu pomocí dotnet ef Tvorba datového modelu Tvorba datového modelu pomocí EF Core je možná pouze tzv. způsobem Code First. Tento způsob definice je založen na principu, že vývojář si nejprve definuje všechny potřebné třídy a jejich vlastnosti v aplikaci, které budou použity k mapování na relační model. K třídám a jejich vlastnostem může přidat metada informace, které slouží k definování jednotlivých vlastností tabulek a sloupců v relační databázi. Ef Core nám dává na výběr ze dvou možností. Buďto metadata můžeme definovat pomocí DataAnnotations atributů, nebo pomocí EntityTypeConfiguration, kde jednotlivé informace můžeme vytvářet pomocí fluent API. Je ale možné tyto dva způsoby kombinovat a použít současně. DataAnnotations DataAnnotations je nejsnazší a nejpřehlednější způsob, jak metada předávat. Všechny informace se předají jako atribute vlastnostem nebo tabulce a je na první pohled viditelné jaká metadata předáváme. Tento způsob nás, ale lehce omezuje a není možné definovat všechny možné metainformace 27

28 EntityTypeConfiguration Konfigurace pomocí fluent api nám dává mnohem více možností, jak metadata definovat. Pro každou námi definovanou entity vytváříme třídu, která je potomkem třídy EntityTypeConfiguration a má funkci, která nám vrací definici entity. Fluent API nám dává možnost přidávat více informací než pomocí DataAnnotations. Jaké informace předáme můžeme upravit i na základě podmínek a konfiguračních souborů aplikace. Nevýhoda tohoto principu je, že není na první pohled známo, jak definice datového modelu bude vypadat Migrace Velkým přínosem entity frameworku je využití tzv. migrací. Migrace nám dávají možnost, jak inkrementálně provádět změny v databázovém schématu a zároveň udržovat databázi synchronizovanou s doménovým modelem bez ztráty dat. Při každé změně v našem doménovém modelu musíme také změnit databázové schéma. Migrace tak funguje na porovnání databázového schématu a našeho současného modelu. Na základě změn připraví scripty, které se mají provést, aby schéma bylo stejné jako definovaný doménový model. Zároveň veškeré provedené migrace jsou uchovávány pod časovou značkou a je tak možné provedené změny vrátit v čase a dostat se do stavu před migrací Práce s daty Entity framework nabízí práci s daty pomocí LINQ (Language Integrated Query) což je jazyk vytvořený v.net Frameworku pro dotazování nad relační databází. Vývojáři tak stačí minimální znalosti jazyka SQL. A může se databáze dotazovat pomocí jazyka LINQ. Jednou z výhod toho principu je, že není nutné mezi jednotlivými funkcemi předávat celé objekty, ale stačí předávat objekt typu IQueryable, který obsahuje příkazy pro selekci dat. Díky čemuž dochází k lepšímu využití paměti systému a optimalizaci systému Modifikace dat Každá instance databázového kontextu si udržuje informace o změnách provedených nad daty. Všechny instance databázového kontextu mají vlastnost ChangeTracker, která sleduje provedené změny nad objektem, jež je obalen proxy třídou a v případě změny objektu 28

29 dojde k zaznamenání dané operace v ChangeTrackeru v databázového kontextu, dokud nepotvrdíme změny provedením komitu Repository & Unit of Work pattern Obrázek 5 Unit Of Work pattern [8] Unit Of Work Unit Of Work pattern nám umožňuje vytvořit zapouzdření nad databázovým kontextem a vytvořit tak abstraktní vrstvu pro práci s daty. Třída DbContext se již sama o sobě chová jako UoW, ale pracuje pořád s konkrétním DB providerem, který je nastaven při spuštění aplikace. Vytvoření vlastní třídy UoW nám dává možnost jednoduše měnit databázové poskytovatele za chodu aplikace. V případě použití nějaké NoSQL databáze jako je například DocumentDB nebo MongoDB, máme možnost implementovat i funkcionalitu pro řízení transakcí a pracovat s nimi stejně jako s relační databází. Repository Vytvořením vlastního repositáře můžeme zapouzdřit práci s databázovým poskytovatelem a následně pomocí Dependency Injection jej předávat jako služby aplikačním službám. Vytvoření repozitáře pro každý typ databázové entity by došlo k vytvoření rudundantního kódu a jeho následné pracné údržbě. Vytvořením generického repozitáře můžeme snadno definovat pouze jeden. Následně vytvořením instance generického repozitáře, kterému 29

30 předáme vždy typ požadované entity dostaneme vždy požadovaný repozitář pro danou entitu, bez nutnosti psaní opakujícího se kódu. Generický repozitář, také můžeme uložit jako službu v Dependency Injection a následně si jej vždy nechat dodat jako službu. 6 Hostování web aplikací na Microsoft Azure Microsoft azure nabízí skvělé služby pro hostování webových aplikací v podobě služby azure app services. Azure app services nabízejí optimalizované řešení pro hostování velkých webových služeb, ale i menších webových stránek. 6.1 Azure app service Azure app services můžeme obsluhovat různé aplikace vyvinuté v různých technologiích mezi nejpopulárnější patří například ASP.NET, ASP.NET Core, PHP nebo Node.js. Je tak možné do tohoto prostředí nasadit libovolnou aplikaci. App services nám v administračním prostředí nabízí přehledný monitoring chodu aplikace, logování chyb a upozornění na bezpečnostní problémy, nebo analýzu výkonnosti aplikace. Samozřejmostí je i přímé napojení na službu Application Insight. Administrátor má tak jasný přehled, v jakém stavu se aplikace nachází a jestli by nebylo vhodné nějakou její část optimalizovat. Výhodou použití řešení Azure web services je možnost zvolit si z několika způsobů nasazení aplikace do produkčního prostředí. Je tak možné snadno celý proces plně zautomatizovat. Základem je mít vytvořen alespoň jeden app service plan. Což je instance serveru, na kterém aplikace funguje. Na jednom app service plan je možné hostovat více než jednu aplikaci a v případě menších aplikací, není potřeba vytvářet pro každou z nich vlastní app service plan. Díky tomu je možné rozložit finanční náklady na provoz jednotlivých aplikací. App service plan lze libovolně měnit a konfigurovat jeho parametry za běhu aplikace. MS Azure nám nabízí vertikální i horizontální škálování. Výhodou MS Azure je funkce auto scale, která umožňuje natavit automatické škálování aplikace. Lze tak nastavit nižší výkon, pokud je zrovna nižší přístup k aplikacím, a naopak zvýšit výkon při větší zátěži, tak aby docházelo k co nejlepšímu využití výkonu serveru a zároveň byli optimalizovány náklady na provoz. 30

31 6.1.1 Azure web jobs Součástí každé app services je možnost využití technologie azure web jobs, která umožňuje spuštění části aplikace na pozadí. Můžeme tak provádět pravidelné rutinní nebo výpočetně náročné operace, aniž bychom zatěžovali hlavní systém aplikace. Web job sdílí stejné prostředí jako webová aplikace. Díky tomu je možné přistupovat například ke konfiguračním souborům aplikace a není potřeba v případě změny měnit konfiguraci jak pro aplikaci, tak web job. V případě škálování aplikace, kdy by bylo spuštěno více instancí, je možné web jobu nastavit že se jedná o tzv. singleton web job, který je sdílený napříč všemi instancemi. Při libovolném počtu instancí, tak vždy bude existovat právě pouze jeden web job. Azure web jobs nabízí několik možností běhu. Volba správného typu web jobu je tak závislá na konkrétním případu užití. Run continuously Proces tohoto typ web jobu je spuštěný stále a reaguje na nějakou předem definovanou událost v systému. Například na změnu souboru na file systému, nebo na Azure Queue Storage Run on a schedule Proces tohoto typ web jobu je vypnutý do té doby, než dojde k aktivaci v předem naplánovaný čas. Vývojář tak může nastavit rutinní operace (např. zasílání reportů na ) na nějaký zvolený čas. Run on demand Proces tohoto typu web jobu je vypnutý do té doby, než dojde k jeho aktivaci pomocí http požadavku. 6.2 Azure SQL Database Azure SQL Database je služba relační databáze, pomocí které můžeme rychle vytvořit, rozšiřovat a škálovat relační aplikace určené pro cloud. Azure SQL Databáze je založená na Microsoft SQL Serveru, proto podporuje všechny funkcionality a rozhraní. Díky tomu je přesun SQL databáze do Azure snadný. Azure SQL databáze podporuje navíc možnost měnit výkon za běhu při obsluhování kritických aplikací. Azure SQL databáze, jako mnoho jiných služeb, jsou automaticky replikovány na dalších třech místech. V případě výpadku či selhání se provoz přesměruje na jednu ze zbylých dvou replik a automaticky se vytvoří nová kopie pro doplnění požadovaného stavu. [6] 31

32 6.3 Azure DocumentDB Azure DocumentDB je služba takzvané NoSQL databáze. Data jsou strukturována do kolekcí (dokumentů) a jednotlivé záznamy jsou reprezentovány jako JSON (JavaScript Object Notation) soubory. Každá kolekce a záznam jsou identifikovány pomocí GUID (Globally Unique Identifier). K datům je možné přistupovat pomocí REST API. Na straně aplikace je tako možné pracovat s entitami jako s objekty, které jsou pomocí contextu serializovány a deserializovány. 7 Popis aplikace Systém pro správu obsahu (CMS). Jedná se o aplikaci, která dává možnost vývojáři, soustředit se především na uživatelskou část aplikace (koncoví web) a nechat systém, aby na základě definice, vytvořil potřebné administrační prostředí. V aplikaci je kladen velký důraz na modularitu, aby bylo možné jednotlivé moduly (komponenty) použít ve více projektech. Nejedná se o systém, ve kterém by si uživatel sám mohl naklikat požadované funkce a rozšíření, ale o nástroj pro vývojáře, který jim umožní moduly přidávat a mít aplikace pod kontrolou po celou dobu vývoje. Systém je postaven na technologii ASP.NTE Core pro serverovou část a klientská část je řešena jako Single Page Application pomocí Angular 2. Jedná se o modulární systém, tudíž je možné používat jen ty části, které jsou potřeba pro daný projekt. Popřípadě není problém si dopsat vlastní modul s rozšířenou funkcionalitou. V následujících kapitolách popíši nejdůležitější části aplikace a způsob jejich implementace a použití při vývoji aplikace. 8 Příprava prostředí Pro zajištění vývoje aplikace je nejprve nutné si připravit vývojové prostředí, tak aby vývojář měl k dispozici všechny nástroje, které jsou potřebné pro vývoj a kompilaci aplikace. 32

33 Dotnet Aplikace, je tvořena pomocí ASP.NET Core (C#), proto musí být na vývojářském prostředí nainstalován dotnet. Při vývoji na operačním systému Windows si toto prostředí může nainstalovat pomocí Visual Studio Installer, kde si v komponentách zvolíme komponenty pro vývoj.net Core aplikací. V případě že pro vývoj používáme jiný operační systém, nebo nemáme k dispozici Visual Studio. Dotnet si můžeme stáhnout jako samostatnou aplikaci z oficiálních internetových stránek 3 Je důležité si zkontrolovat, aby verze dotnet odpovídala verzi aplikace. Aplikace je vyvíjena ve verzi netcoreapp2.1. Pokud by byla nainstalovaná jiná verze dotnet frameworku nebylo by možné aplikace zkompilovat a uživatel by byl informován o špatné verzi a jak má postupovat při instalaci požadované verze. Node.js Vzhledem k tomu že vývoj klientské části je napsán v Angular 2, je potřeba, aby na vývojovém prostředí bylo nainstalováno prostředí node.js, které nám umožní spouštět kompilační nástroje pro angular a instalaci balíčkovacího systému. 4 Yarn Balíčkovací systém pro instalaci balíčků třetích stran je použit Yarn. Jedná se o nadstavbu npm, které nabízí rychlejší instalaci balíčků a také dává možnost vývojáři pracovat offline. Pokud byl balíček již jednou na vývojovém prostředí nainstalován, tak se nemusí znovu stahovat z online repozitáře, ale nahraje se z file systému prostředí. Vývojář tak nemusí být po celou dobu vývoje aplikace online. 5 Angular compiler (NGC) Pro kompilace klientské části je potřeba mít nainstalován kompiler pro angular. Kompiler se stahuje jako součást balíčku aplikace, ale je možné ho mít nainstalován přímo v systému a využívat tak rozšířené možnosti, které angular compiler nabízí

34 9 Architektura systému Architektura systému je navržena, tak aby se skládala z modulů. Systém obsahuje několik základní modulů, které je potřeba vždy implementovat pro zajištění chodu celé aplikace. Systém pak lze následně rozšiřovat a modifikovat pomocí vlastních modulů, které si každý vývojář může vytvořit a následně integrovat do aplikace. Na architekturu systému se můžeme dívat ze dvou pohledů. Prvním pohledem je N- Layer pohled, který nám zobrazuje rozdělení logických bloků aplikace. Druhý pohled je zaměřeni již na napojení jednotlivých modulů. 9.1 N-layer pohled Obrázek 6 N-Layer pohled (vlastní zpracování) Vrstva infrastruktury Vrstva infrastruktury zajišťuje interakci s externími systémy pomocí získávání, ukládání a poskytování dat, když je o ně požádáno. Hlavním účelem vrstvy pro tento systém je zajistit napojení na datové uložiště. Doménová vrstva Doménová vrstva obsahuje služby pro správu jednotlivých doménových služeb a entity. Zároveň obsahuje rozhraní pro napojení na repozitář z infrastrukturové vrstvy a díky tomu je možné použít libovolné datové uložiště, nebo jej za chodu měnit. Dalším aspektem této vrstvy je definice všech požadovaných tříd pro definici komponent jako jsou například formuláře, tabulky atd. 34

35 Aplikační vrstva Aplikační vrstva obsahuje již komplexní funkce, které pracují s doménovými službami. Jedná se již o konkrétní případy užití, které se mají v systému vykonávat. Vrstva také obsahuje Data Transfer Object což jsou objekty, které se předávají uživateli. Jedná se o objekty, které se skládají z požadovaného výsledku a obsahují veškeré informace, které uživatel potřebuje. Distribuční vrstva Distribuční vrstva obsahuje kontroléry, které se starají o komunikace mezi klientem a aplikací. Kontroléry jsou uzpůsobeny pro komunikace pomocí REST API rozhraní. Je možné vytvářet libovolné vlastní kontroléry pro specifické účely, nebo je možné použít již předem definované (generované při spuštění aplikace), které zajišťují například vygenerování formuláře, nebo tabulek. Prezentační vrstva Prezentační vrstva zobrazuje uživateli požadované výsledky a pomocí ní může komunikovat s distribuční vrstvou. Prezentační vrstva obsahuje dvě rozhraní. První rozhraní je vygenerovaný systém pro správu obsahu, kde administrátor může upravovat obsah webové prezentace. Druhá část je webová prezentace, kterou vidí veřejní návštěvníci webové stránky. Společné části architektury Všechny vrstvy architektury mají přístup ke společným funkcím, které jsou potřeba napříč celým systémem. Dependency injection služba, která zajišťuje vkládání závislostí do jednotlivých služeb, které potřebují komunikovat s jinou službou. Jako Dependency Injection kontejner je použit defaultní kontainer, který nabízí ASP.NET Core. Pro kontejner je vytvořena ještě nadstavba, která zajišťuje snadnější přístup ke službám. Logování logovací služba, která se stará o zaznamenávání provedených akcí systémem, nebo ukládání chybových hlášení. Objektové mapování služba, které zajišťuje mapování dat z jednotlivých objektů do požadované podoby. Tato služba je pro systém velmi důležitá, protože je potřeba provádět transformaci požadovaných dat do vyžádané podoby a obohacovat je o metadata, pomocí kterých se následně systém rozhoduje, jak s daty pracovat. 35

36 Cache paměť paměť pro ukládání výsledků, aby některé náročnější části nemusely být vykonávány znovu, pokud se výsledek nemění. Konfigurace služba zajišťuje přístup ke konfiguraci systému, aby bylo možné číst nastavení, definované v konfiguračním souboru aplikace. Pro aplikační, distribuční a prezentační vrstvu jsou k dispozici ještě následující služby. Autorizace / Autentifikace Služba zajišťující ověření uživatele a jeho práva k vykonání požadované akce. Session služba obsahující informace o aktuální session spojení mezi uživatelem a systémem, služba umožňuje i přístup ke cookies souborům, nebo lokálnímu uložišti. Unit Of Work Služba slouží k provádění transakcí při modifikaci dat v uložišti. Správa modulů služba zajišťuje přístup k požadovaným modulům, které aplikace integruje. 9.2 Pohled na moduly Druhým pohledem na architekturu je pohled rozdělující jednotlivé moduly systému. 36

37 9.2.1 Základní moduly systému Obrázek 7 Základní moduly systému (vlastní zpracování) V této kapitole budou jsou popsány základní moduly, které zajišťují chod aplikace a nástroje pro vytvoření požadovaného prostředí aplikace. Infrastructure module Základním modulem je modul zajišťující infrastrukturu celé aplikace. Modul obsahuje základní definice a nástroje pro integraci dalších modulů a poskytuje rozhraní pro společné služby, které mohou ostatní moduly využívat. Jednou z nejdůležitějších částí modulu je třída DynModule, která obsahuje předpis pro ostatní moduly a funkce pro jejich registraci do systému. Pro zajištění správné integrace, tak každý modul musí být potomkem této třídy. Spuštění modulu se skládá ze tří kroků 1. PreIninitialize tato funkce slouží k registraci služeb pomocí dependency injection, tak aby ostatní moduly mohly k těmto službám přistupovat. 2. Initialize v této funkci dochází k nastavení služeb a registraci datového modelu pro entity framework. Funkce může využívat všechny služby, které byly registrovány v první fázi spuštění. 3. PostInitialize Funkce se spouští jako poslední a slouží pro kontrolu, jestli vše proběhlo v pořádku, nebo k provedení akcí, které byly registrovány v druhé fázi spuštění. Další důležitou částí modulu je třída DynModuleLoader a DynBootstraper. DynModuleLoader je služba, která zajišťuje nalezení všech registrovaných modulů a jejich závislostí. Moduly jsou procházeny rekurzivně. Vstupním bodem je hlavní modul, což je modul, který je vytvořen ve front-endové části aplikace. Následně v závislosti na atributu třídy DependesOn jsou rekurzivně nalezeny všechny požadované moduly. Modul je procházen a registrován pouze v případě, že ještě nebyl nalezen v jiném modulu, tak aby nedocházelo k zacyklení načtení. DynBootstraper Služba DynBootsraper zajišťuje při spuštění aplikace registraci všech nalezených modulů ze služby DynModuleLoader a zajistí jejich spuštění. 37

38 Dashboard module Každá moderní aplikace, musí obsahovat nějaký vstupní bod, který uživatel vidí hned po přihlášení do systému. Nejčastěji se jedná o nástěnku, která obsahuje přehled a důležité informace, které uživatel potřebuje vědět, aby se rychle dokázal z orientovat a začít efektivně pracovat se systémem. Může se jednat na příklad o informaci, že došlo k registraci nového uživatele a je potřeba jej schválit, nebo informace o tržbách z elektronického obchodu. Do tohoto modulu je možné registrovat komponenty, které se mají uživateli na nástěnce zobrazit. Je tak možné bez problému pro každý modul vytvořit sadu komponent, které uživateli mohou nabídnout rychlý přehled. Komponentu tak stačí jen vytvořit a zaregistrovat v poskytnuté službě, tohoto modulu. Systém se pak postará o dodání všech těchto komponent při přihlášení do aplikace uživateli. Pro vytvoření komponenty, je možné využít některé předem definované komponenty, a říct jim pouze jaké data mají zobrazovat, nebo je možné si napsat vlastní komponentu v angularu a tu následně zaregistrovat. Uživatelské rozhraní nástěnky se skládá z CSS Grid, což umožňuje velmi snadnou manipulaci s nastavením vlastního rozložení, tak aby si jej mohl každý uživatel přizpůsobit podle sebe. Pomocí CSS Grid Area je možné si rozložení přeskládat podle potřeby uživatele. Forms module Důležitou součástí aplikace je modul pro automatické generování formulářů. Cílem aplikace je, aby se na základě definovaného modelu vytvořily požadované formuláře a editory pro práci s obsahem. Tuto funkčnost právě zajišťuje tento modul. Modul obsahuje třídu Form od níž mohou formuláře dědit. Tato Třída předává potřebné vlastnosti pro generování formuláře. Každý formulářový prvek se skládá z vlastností, které implementují rozhraní IFormField. V konstruktoru je pak možné jednoduše definovat jaký formulářový prvek a jeho vlastnosti jsou pro každý prvek potřeba. Pro definování formulářového prvku je do třídy vložen DynFormBuilder, který nám v konstruktoru umožňuje formulářové prvky definovat pomocí Fluent API. Díky tomu je možné formulář upravovat i na základě podmínek, nebo jiných služeb. Modul obsahuje základní formulářové prvky a validace. Není však problém si napsat vlastní formulářové prvky nebo validace a ty následně používat. Předpokladem je že prvek 38