Nstroje a techniky pro MVC aplikace TNPW 2

Nástroje a techniky pro MVC aplikace TNPW 2 Ing. Jiří Štěpánek

Obsah přednášky • Potřeba a vhodnost použití • Nástroje a techniky související (nejen) s tvorbou MVC webových aplikací • ORM – přístup k datům • Dependency injection kontejner • Mocking • Unit testy

Potřeba využití • Samotný MVC architektonický vzor (z toho postavený framework) řeší pouze rozložení funkčnosti do vrstev • Představené nástroje vždy řeší pouze konkrétní aspekt • Přínosy • Přehlednější kód • Nižší provázanost komponent • Větší znovupoužitelnost • Flexibilita • Podstatné zjednodušení práce • Úspora času

Přístup k datům • Jedna z nejdůležitějších úloh aplikace • Data jsou uložena zpravidla v relační databázi • Rozdílná reprezentace entit v relačním a objektovém pojetí • Přímý přístup k datům • Ruční specifikace SQL dotazu potřebného pro konkrétní operaci • Využití tříd dané platformy pro odeslání dotazu • Přijetí odpovědi ve formátu řádků dat • Ruční transformace řádkových dat na objekty, které aplikace dále používá • Obráceně – transformace objektů do SQL dotazu (parametrizace)

Přímý přístup k datům using (Sql. Connection c = new Sql. Connection( Properties. Settings. Default. Data. Connection. String)) { c. Open(); // Vytvoří data adapter s definicí select příkazu using (Sql. Data. Adapter a = new Sql. Data. Adapter("SELECT * FROM Employee. IDs", c)) { // plnění datové tabulky Data. Table t = new Data. Table(); a. Fill(t); // Definice dat. tabulky jako zdroje pro GV data. Grid. View 1. Data. Source = t; } }

Přímý přístup k datům - výhody • Nejrychlejší způsob provedení operace (pokud je správně naprogramováno) • K realizaci stačí již připravené třídy na dané platformě • Absolutní kontrola nad SQL kódem • …. to je asi vše

Přímý přístup k datům - nevýhody • Obrovské množství redundantního kódu • Závislost na konkrétním DB řešení již v době návrhu a z toho vyplývající nemožnost snadné změny DB backendu • Náchylnost ke zranitelnostem • Nutná ruční kontrola všech vstupních parametrů vytvářených dotazů • Při změně datového modelu je nutné měnit jak SQL dotazy, tak příslušné metody, které se starají o transformaci relačních dat na objekty a naopak • Nemožnost odhalení určitých typů chyb ještě před kompilací aplikace • Množství obslužného kódu může v některých případech neúměrně vzrůst, jeho definice může být velmi komplikovaná (např. zachycení dědičnosti tříd) • Absence určitých technik (cache např. )

ORM (Objektově Relační Mapování) • Technika abstrakce nad relační databází, kdy se v aplikaci pracuje výhradně s aplikačními objekty. • O konverzi mezi relačními daty a objekty se stará ORM framework • Na jedné straně stojí definice aplikačních tříd (agregace, kompozice, kolekce…) • Na druhé straně existuje (nebo ještě nemusí) databázové schéma (tabulky, cizí klíče, omezení…) • ORM framework se stará o mapování primitivních atributů třídy, kolekcí, referenčních uživatelských typů na tabulky a jejich sloupce

ORM • Výhody • Mimo prvotního seznámení a nastavení představuje ORM framework obrovské ulehčení práce na úrovni datové vrstvy. • Vytváří abstrakci nad relační databází, takže programátorská práce s daty spočívá pouze v práci s aplikačními objekty • Možnost generování databázového schématu na základě aplikačních objektů a mapování (zajištění synchronizace) • Umí řešit objektovou dědičnost • Nevýhody • Při nesprávném použití může znamenat zátěž • Některé primitivní operace (typicky dávkový update nebo delete) nejsou jednoduše realizovatelné • Nutnost konkrétnímu frameworku porozumět • Konkrétní ORM frameworky • Entity Framework, Nhibrnate , … (. net) • Hibernate, Eclipse. Link, … (java) • Doctrine, Fuel. PHP, . … (php)

NHibernate - příklad • Konfigurace frameworku • XML soubor hibernate. cfg. xml

NHibernate – příklad • Mapování třídy pomocí xml

NHibernate - příklad • Mapování třídy, použití Fluent NHibernate • Odstínění od xml, chyba v mapování se dá zjistit již v době návrhu

NHibernate - repozitáře • Při vhodném návrhu je možné vytvořit předka repozitářů, který obstarává základní operace (nutnost použití rozhraní, generik, …)

ORM – Strategie výběru • výběr objektů se řídí tzv. strategií výběru • NHibernate poskytuje 4 strategie výběru • Okamžitá strategie • Asociované objekty jsou vybrány okamžitě pomocí sekvenčního čtení z databáze nebo z cache • Hladová strategie • Objekty a kolekce jsou vybrány společně s rodičem pomocí SQL vnějšího spojení (outer join) a další přístupy do databáze nejsou třeba • Líná strategie • Objekty a kolekce jsou vybírány líně až při prvním přístupu k nim – tento přístup zapříčiní další dotaz nad databází, pokud hledaná data nejsou v cache • Dávková strategie • • • Dokáže zvýšit výkon líné strategie – získá najednou sadu objektů/kolekcí v případě, že je líné získávání dat aktivováno Ostatní frameworky poskytují víceméně stejné strategie Na volbě strategie závisí výkon!! Je třeba určit, které atributy objektu je nutné znát ihned a které nemusí být potřeba. Strategie výběru je specifikována v mapování, je možné ji změnit při dotazu

ORM – Strategie výběru – příklad (Lazy. Loading) • Kolekce „Answered. Questions“ mapované třídy se nenačítá okamžitě, ale až při prvním programovém přístupu k této property. • Entita je ve skutečnosti „obalena“ proxy třídou, která si na sobě drží instanci nhibernate session, jakmile je zavoláno get na kolekci, provede se dotaz na DB a naplnění kolekce.

ORM - Doporučení • Naučte se používat jeden framework pro danou platformu • Dbejte na správný návrh • Zajistěte znovupoužitelnost kódu • Pro obecné operace vytvořte generického předka a používejte dědičnost • Vhodně volte strategii výběru jednotlivých tříd • Neřešit ji znamená to samé jako napsat „SELECT * FROM …“ • Použijte nějaký SQL profiler pro zobrazení dotazů, které jsou generovány a posílány DB enginu • Projděte si vhodnou literaturu, kde jsou řešeny základní vzorové případy užití. • V případě dávkových příkazů (UPDATE, DELETE) raději použijte např. uloženou proceduru na straně sql serveru

Dependency Injectoin • Technika odstraňování úzkých vazeb mezi třídami • Při návrhu jako první vzniká rozhraní, poté třída(y) které ho implementují • DI kontejner rozhodne, která implementační třída bude použita (podle uživatelsky definovaných prvidel) • Instance nevytváříme pomocí klíčového slova new ale pomocí služby DI kontejneru, která vrátí vytvořenou instanci • Pravidla, která implementační třída bude vrácena, za jakých podmínek a v jakém režimu jsou definována v konfiguraci DI kontejneru. • Pro. net Castle Windsor, Spring. NET, Ninject (často využíván v souvislosti s asp. net mvc aplikacemi) a další…

Dependency injection – příklad (obecný postup) • Vytvoření rozhraní a implementační třídy (tříd)

Dependency injection – příklad (Ninject) • Vytvoření pravidel (nejjednodušší binding) • V aplikaci se pak získá instance přes DI kontejner

Ninject – reálný příklad – constructor injection • V MVC aplikaci je vytvořen kernel DI kontejneru a proveden binding (Ninject), následně jsou získány konkrétní implementace v konstruktoru kontroleru

Ninject – využití v MVC aplikaci - příklad • Konkrétní instance je do konstruktoru MVC kontroleru injektována DI kontejnerem na základě definovaných pravidel. • Constructor Injection (jedna z metod využití DI) • V kódu pak lze instanci získat např. takto

Ninject - Contextual Binding • Binding na základě kontextu objektu (podmíněný) • Velká škála možností, jak definovat pravidla

Dependency Injection - doporučení • Jedná se o běžně používanou programátorskou techniku, proto se ji snažte porozumět a naučte se ji používat • Při návrzích netriviálních projektů může sehrát klíčovou roli v rozšiřitelnosti aplikace, testování • Využívejte možnosti DI kontejneru • Scopes (určuje kolik instancí se tvoří v jakém případě = singleton, vlákno, request, …) • Podmíněný binding • Různé metody injection

Mocking • Vytváření objektů reálných aplikačních tříd a simulace jejich konkrétního chování • V reálných aplikacích jsou třídy často složitě provázány a vytváření jejich instancí mimo standardní kontext je někdy komplikované • Mocking dovoluje vytvořit jednoduše instanci třídy a předepsat jí požadované chování • Výhodné při jednotkových i jiných testech • Moq, Fake. It. Easy, Nsubstitute a další (. net)

Moq - příklad

Jednotkové testy (Unit. Test) • Automatické testování a ověřování správnosti implementace systému • Testuje se správné fungování dílčích částí (jednotek) zdrojového kódu • Ideálně by měly být jednotlivé testy na sobě nezávislé a měla by být ověřována pouze konkrétní fukčnost • Zde je vhodné použít pomocné objekty (Mocking), které simulují konkrétní fungování • Jednotkové testy jsou v kompetenci programátora, některé metodiky vývoje na jednotkových testech stojí (TDD) • Každá (rozumná) vývojová platforma má k dispozici nástroje pro jednotkové testování

Unit. Test – příklad ASP. NET MVC

Unit. Test • Testujte co je třeba testovat • Vyhněte se zbytečné komplexnosti objektů (použít mocking) nebo testů (pište testy jednoduše, bez zbytečných závislostí) • Jeden test = ověřování jedné funkcionality • Používejte Assert metody • Automatizujte jednotkové testování • Jednotkové testy se dají šikovně rozdělit do skupin • Lze automaticky spustit jak jeden konkrétní test, tak skupinu, nebo všechny naráz • Jednotkové testy pomohou odhalit nekonzistentní nebo chybné chování aplikace • Správně napsané jednotkové testy ušetří mnoho času při vývoji

Doporučené čtení • FREEMAN, Adam. Pro ASP. NET MVC 5. 5 th ed. New York, N. Y. : Apress, 2013. ISBN 9781430265306. • Learning NHibernate 4, Packt publishing, 2015 • http: //download. microsoft. com/download/0/f/b/0 fbfaa 46 -2 bfd-478 f 8 e 567 bf 3 c 672 df 9 d/getting%20 started%20 with%20 entity%20 framework %206%20 code%20 first%20 using%20 mvc%205. pdf • http: //iliasoft. ir/Download/Apress_Entity_Framework_6_Recipes. pdf • https: //www. danylkoweb. com/Blog/the-ultimate-guide-to-unit-testing -in-aspnet-mvc-E 2 • https: //github. com/Moq/moq 4/wiki/Quickstart

Konec prezentace Otázky / Připomínky