Implementační přístup Filosofie
vodopádový přístup
Vodopádový přístup k implementaci aplikace vyžaduje, aby návrhář konzultoval s jedním nebo více zástupci organizace koncového uživatele a zapsal si všechny specifikace aplikace. Specifikace se obvykle dodávají v sadě funkčních dokumentů nebo případů použití napsaných tak, aby koncový uživatel mohl dokumenty snadno číst a porozumět jim.
Koncový uživatel tyto dokumenty podepíše a dokumenty jsou poté shromážděny týmem technických návrhů, který navrhuje aplikaci a vytváří různé artefakty, jako jsou diagramy modelů tříd, stavové diagramy, diagramy aktivit a datové modely. Cílem této fáze je napsat vše tak podrobně, aby vývojář neměl problém vytvořit potřebný kód. Probíhá formální předání návrhu vývojovému týmu a testovacímu týmu. Po dodání začne vývojový tým kódovat a testovací tým použije technický návrh v kombinaci s případy použití k vytvoření testovacích případů a testovacích scénářů.
Poté, co vývojový tým dokončí kódování, je kód předán testovacímu týmu. Testovací tým provádí testy, které navrhl na základě požadavků a podrobného návrhu. Případné problémy opraví vývojový tým. Po dokončení procesu testování a oprav je aplikace doručena koncovému uživateli k akceptačnímu testování. Koncový uživatel provede závěrečnou kontrolu, zda aplikace vyhovuje původním požadavkům. V případě schválení schválí hotový výrobek a projekt je dokončen. Poté, co vývojový tým dokončí kódování, je kód předán testovacímu týmu.
Testovací tým provádí testy, které navrhl na základě požadavků a podrobného návrhu. Případné problémy opraví vývojový tým. Po dokončení procesu testování a oprav je aplikace doručena koncovému uživateli k akceptačnímu testování. Koncový uživatel provede závěrečnou kontrolu, zda aplikace vyhovuje původním požadavkům. V případě schválení schválí hotový výrobek a projekt je dokončen. Poté, co vývojový tým dokončí kódování, je kód předán testovacímu týmu. Testovací tým provádí testy, které navrhl na základě požadavků a podrobného návrhu.
Případné problémy opraví vývojový tým. Po dokončení procesu testování a oprav je aplikace doručena koncovému uživateli k akceptačnímu testování. Koncový uživatel provede závěrečnou kontrolu, zda aplikace vyhovuje původním požadavkům. V případě schválení schválí hotový výrobek a projekt je dokončen.
Koncový uživatel provede závěrečnou kontrolu, zda aplikace vyhovuje původním požadavkům. V případě schválení schválí hotový výrobek a projekt je dokončen. Koncový uživatel provede závěrečnou kontrolu, zda aplikace vyhovuje původním požadavkům. V případě schválení schválí hotový výrobek a projekt je dokončen.
Při použití vodopádového přístupu může mít projekt více či méně fází, ale klíčovým rysem je velmi formální začátek a konec každé fáze s velmi formálními výstupy.
Výhodou vodopádového přístupu je, že odpovědnost týmu odpovědného za každou fázi je větší. Je jasné, co potřebují dodat, kdy to potřebují doručit a komu to potřebují doručit. Vývojový tým často nebude muset s uživatelem komunikovat. To může být velmi užitečné při outsourcingu vývoje do jiné země.
Hlavní nevýhodou vodopádového přístupu je to, že v prostředí, kde je vše organizováno velmi formálním způsobem, klesá flexibilita reagovat na změny. I stěhování je potřeba organizovat. Zdá se, že jen velmi málo společností to dělá efektivně, což často vede k výraznému zvýšení režijních nákladů. Kvůli řízení nákladů na projekt některé společnosti dokonce odkládají jakékoli změny požadavků až do počátečního dodání aplikace, čímž efektivně dodávají aplikaci, která nesplňuje potřeby koncového uživatele.
agilní vývoj
Mnoho dlouhodobých projektů vývoje softwaru překročilo rozpočet a nedodalo produkt včas. Předpokladem filozofie agilního vývoje softwaru je minimalizovat rizika vývojem softwaru v krátkých časových intervalech, nazývaných iterace, které obvykle trvají jeden až čtyři týdny. Každá iterace je jako svůj vlastní miniaturní softwarový projekt a zahrnuje všechny úkoly nezbytné k uvolnění přírůstku nových funkcí: plánování, analýzu požadavků, návrh, kódování, testování a dokumentaci. I když iterace nemusí přidat dostatek funkcí, aby zaručila vydání produktu, agilní softwarový projekt si klade za cíl být schopen vydat nový software na konci každé iterace. Na konci každé iterace tým přehodnotí priority projektu.
Cílem agilního vývoje softwaru je dosáhnout spokojenosti zákazníků prostřednictvím rychlého a nepřetržitého dodávání užitečného softwaru; vždy s cílem vybudovat to, co zákazník potřebuje; pozdní změny požadavků spíše vítat, než se bránit; pravidelně se přizpůsobovat měnícím se okolnostem; mít úzkou a každodenní spolupráci mezi podnikateli a vývojáři, ve které je rozhovor tváří v tvář nejlepší formou komunikace.
Hlavní výhodou agilního vývoje softwaru je flexibilita při řešení změn, vždy s cílem dodávat podle obchodních potřeb. Nevýhodou je samozřejmě nárůst složitosti správy rozsahu, plánování a rozpočtování. Dalším častým rizikem je omezená pozornost věnovaná (technické) dokumentaci.
Přírůstkový vývoj
Inkrementální vývoj softwaru je kombinací agilního a vodopádového vývoje. Aplikace je navržena, implementována a testována postupně, takže každý přírůstek může být doručen koncovému uživateli. Projekt není dokončen, dokud není dokončen poslední přírůstek. Jeho cílem je zkrátit kaskádu definováním mezilehlých přírůstků a využitím některých výhod agilního vývoje. Na základě zpětné vazby obdržené u předchozího přírůstku lze provést úpravy při dodání dalšího přírůstku. Další přírůstek se může skládat z nového kódu i z úprav dříve poskytnutého kódu.
Výhodou je, že formality zůstávají na svém místě, ale řízení změn je jednodušší. Náklady na vícenásobné testování a nasazení aplikace budou vyšší, než kdybyste to udělali jen jednou.
Program Flow Control
Volba přístupu k řízení toku programu je velmi architektonický úkol. Cílem je vytvořit plán vaší aplikace, kde jakmile začnete přidávat funkcionalitu a kód, zdá se, že vše má své vlastní místo. Pokud jste někdy recenzovali nebo psali vysoce kvalitní kód, rozumíte tomuto principu.
Kód organizátora
Prvním krokem při navrhování toku programu je uspořádat kód vytvořením sady pravidel, která pomohou vytvořit plán nebo obrys aplikace. Údržba, ladění a oprava chyb bude jednodušší, protože kód je umístěn na logickém místě. Jakmile uděláte základy, můžete si vybrat přístup k implementaci logiky vaší aplikace.
Návrhové vzory by měly hrát důležitou roli při návrhu řízení toku programu. V průběhu let bylo napsáno mnoho kódu a bylo navrženo mnoho řešení pro opakující se problémy. Tato řešení jsou uspořádána v návrhových vzorech. Použití návrhového vzoru na běžný problém návrhu softwaru vám pomůže vytvořit řešení, která jsou snadno rozpoznatelná a mohou být implementována vašimi kolegy. Jedinečné problémy budou stále vyžadovat jedinečná řešení, ale při jejich řešení můžete použít návrhové vzory.
Vytvoření projektu
vrstvy
Prvním krokem je zvážit logické vrstvy. Všimněte si, že vrstvy nejsou stejné jako vrstvy, často jsou zaměňovány nebo dokonce považovány za stejné.
vrstvy versus vrstvy
Vrstvy jsou o vytváření hranic ve vašem kódu. Horní vrstva může mít odkazy na kód ve vrstvách níže, ale vrstva nikdy nemůže mít odkaz na kód ve vrstvě výše. Vrstvy označují fyzické rozložení vrstev na více počítačích. Například v třívrstvé aplikaci je uživatelské rozhraní navrženo tak, aby běželo na stolním počítači, aplikační logika je navržena tak, aby běžela na aplikačním serveru a databáze běží na databázovém serveru. vrstva se může skládat z několika vrstev.
Obrázek 8-1: Základní třívrstvá organizace
Vrstvy se týkají úrovní abstrakce. Vrstvy zobrazené na obrázku 8-1 platí pro většinu aplikací. Tyto úrovně se také označují jako tři hlavní vrstvy a mohou mít různá další jména. Kód v prezentační vrstvě může zpravidla volat služby v aplikační logické vrstvě, ale aplikační logická vrstva nesmí volat metodu v prezentační vrstvě. Prezentační vrstva by nikdy neměla přímo volat vrstvu pro přístup k datům, protože by to obcházelo povinnosti implementované vrstvou aplikační logiky. Vrstva pro přístup k datům by nikdy neměla volat vrstvu aplikační logiky.
Vrstvy jsou jen abstrakce a pravděpodobně nejjednodušší způsob, jak vrstvy implementovat, je vytvořit složky v projektu a přidat kód do příslušné složky. Užitečnějším přístupem by bylo umístit každou vrstvu do samostatného projektu, čímž by se vytvořily samostatné sestavy. Výhodou umístění vaší aplikační logiky do sestavení knihovny je to, že vám umožní vytvářet testy jednotek pomocí Microsoft Visual Studio nebo NUnit k testování logiky. To také vytváří flexibilitu při výběru umístění každé vrstvy.
Fyzické vrstvy
V podnikové aplikaci byste očekávali, že budete mít více klientů pro stejnou logiku. Ve skutečnosti to, co dělá aplikaci podnikovou aplikací, je to, že bude nasazena ve třech vrstvách: klient, aplikační server a databázový server. Aplikace Microsoft Office Access vytvořená obchodním oddělením vaší společnosti, přestože je pro obchodní oddělení velmi důležitá, není podnikovou aplikací.
Všimněte si, že aplikační logika a vrstvy přístupu k datům jsou na aplikačním serveru často nasazovány společně. Součástí návrhu projektu je výběr, zda přistupovat k aplikačnímu serveru pomocí vzdáleného .NET nebo webových služeb. Ať si vyberete kteroukoli možnost, přidáte nějaký kód pro snadný přístup ke vzdáleným službám v prezentační vrstvě. Pokud pro přístup ke službám na svém aplikačním serveru používáte webové služby, Visual Studio .NET udělá práci za vás a vygeneruje kód proxy, čímž automaticky zajistí implementaci vzoru vzdáleného proxy.
Přidávání vzorů do vrstev
Tři základní vrstvy poskytují přehled na vysoké úrovni. Pojďme přidat některé strukturální vzory, abychom vytvořili robustní podnikovou architekturu. Výsledek je znázorněn na obrázku 8-2.
Zaměřte se na vrstvu aplikační logiky. Obrázek 8-2 ukazuje, že přístup k aplikační logice využívá vzor fasády. Fasáda je objekt, který poskytuje zjednodušené rozhraní pro větší část kódu, jako je knihovna tříd. Fasáda může snížit závislosti externího kódu na vnitřním fungování knihovny, protože většina kódu používá fasádu, což umožňuje větší flexibilitu při vývoji systému. Za tímto účelem bude fasáda poskytovat hrubozrnné rozhraní pro kolekci jemnozrnných objektů.
rozhodovací tok
Řízení toku programu, známé také jako tok rozhodování, se týká toho, jak navrhujete služby ve vrstvě aplikační logiky, nebo, jak jste viděli v předchozím odstavci, jak navrhujete metody ve vaší fasádě.
Existují dva přístupy k organizaci vašich služeb:
- akčně orientované
- státem řízený
Akčně orientovaný přístup
Uspořádáním služeb na základě akcí uživatele implementujete aplikační logiku tím, že nabídnete služby, z nichž každá zpracovává konkrétní požadavek z prezentační vrstvy. Toto je také známé jako vzor transakčního skriptu. Tento přístup je oblíbený, protože je jednoduchý a vypadá velmi přirozeně. Příklady metod, které se řídí tímto přístupem, jsou BookStoreService.AddNewOrder(Objednávka) a BookStoreService.CancelOrder(int orderId).
Logika potřebná k provedení akce je v rámci metody implementována velmi sekvenčně, díky čemuž je kód velmi čitelný, ale také obtížnější pro opětovné použití. Použití dalších návrhových vzorů, jako je vzor modulu tabulky, může pomoci zvýšit znovupoužitelnost.
Státem řízený přístup
Je také možné implementovat rozhodovací tok aplikace mnohem více stavově orientovaným způsobem. Služby nabízené aplikačním serverem jsou obecnější povahy, například BookStoreService.SaveOrder (Objednávka). Tato metoda prozkoumá stav objednávky a rozhodne, zda přidat novou objednávku nebo zrušit existující objednávku.
Projekty datových struktur
Při navrhování datových struktur musíte udělat několik možností. První volbou je mechanismus ukládání dat, druhou zamýšlené použití dat a třetí požadavky na verzi. Existují tři způsoby, jak se dívat na návrhy datových struktur:
- Služby nabízejí data; data jsou odrazem relační databáze.
- Data musí být mapována na objekty a služby poskytují přístup k objektům.
- Data nabízená službami musí být založena na schématu.
Výběr jednoho ze tří jako základ struktury toku dat by měl být proveden v rané fázi procesu návrhu. Mnoho společností má firemní směrnici, která nařizuje jednu ze tří možností pro všechny projekty, ale pokud je to možné, měli byste přehodnotit možnosti pro každý projekt a zvolit optimální přístup pro daný projekt.
Výběr modulu pro ukládání dat
Při návrhu aplikace budete nepochybně muset navrhnout nějaký druh úložiště dat. K dispozici jsou následující úložiště a formy ukládání dat:
- Záznam
- soubor app.config
- xml soubory
- prosté textové soubory
- Databáze
- řazení zpráv do fronty
Každý obchod má své vlastní jedinečné vlastnosti a může být přizpůsoben specifickým požadavkům.
Návrh datového toku
Datový tok pomocí ADO.NET
Implementací datově orientovaných služeb ve vrstvě aplikační logiky navrhnete svůj datový tok pomocí ADO.NET. Knihovna tříd .NET Framework poskytuje rozsáhlé aplikační programovací rozhraní (API) pro manipulaci s daty ve spravovaném kódu. Rozhraní API, označované jako ADO.NET, lze nalézt v oboru názvů System.Data. Úplné oddělení datových nosičů a datových úložišť je důležitým konstrukčním prvkem ADO.NET. Třídy jako DataSet, DataTable a DataRow jsou navrženy tak, aby ukládaly data, ale neuchovávaly žádné znalosti o tom, odkud data pocházejí. Jsou považováni za agnostické zdroje dat. Samostatná sada tříd, jako je SqlConnection, SqlDataAdapter a SqlCommand, se stará o připojení ke zdroji dat, načítání dat a naplňování DataSet, DataTable a DataRow. Tyto třídy jsou umístěny v dílčích jmenných prostorech jako System.Data.Sql, System.Data.OleDB, System.Data.Oracle a tak dále. V závislosti na tom, ke kterému datovému zdroji se chcete připojit, můžete třídy používat ve správném jmenném prostoru a v závislosti na rozsahu produktu, který používáte, zjistíte, že tyto třídy nabízejí více či méně funkcí.
Vzhledem k tomu, že DataSet není připojen ke zdroji dat, lze jej poměrně úspěšně použít pro řízení toku dat v aplikaci. Obrázek 8-5 ukazuje tok dat při tomto postupu.
Pojďme se na tento projekt podívat a představme si, že se někdo přihlásil do vašeho knihkupectví a objednal si tři knihy. Prezentační vrstva spravovala stav nákupního košíku. Zákazník je připraven provést objednávku a uvedl všechny potřebné údaje. Rozhodne se odeslat objednávku. Webová stránka transformuje všechna data do DataSet obsahující dva DataTables, jeden pro objednávku a jeden pro objednávku; vloží DataRow pro objednávku; a vloží tři DataRows pro řádky objednávky. Webová stránka poté zobrazí tato data zpět uživateli ještě jednou, sváže ovládací prvky dat s DataSet a zeptá se Are you sure? Uživatel potvrdí požadavek a ten je odeslán do logické vrstvy aplikace. Vrstva aplikační logiky zkontroluje DataSet, aby zjistila, zda všechna požadovaná pole mají hodnotu, a provede kontrolu, zda má uživatel více než 1000 US$. 00 na neuhrazené účty. Pokud vše půjde dobře, DataSet je předán vrstvě pro přístup k datům, která se připojí k databázi a vygeneruje příkazy vložení z informací DataSet.
Použití DataSet tímto způsobem je rychlý a efektivní způsob, jak vytvořit aplikaci a využít sílu Framework Class Library a schopnost ASP.NET vázat data na různé ovládací prvky, jako je GridView, proti DataSet. Namísto použití jednoduchých objektů DataSet můžete použít objekty Typed DataSet a zlepšit práci s kódováním implementací kódu do prezentační vrstvy i do vrstvy aplikační logiky. Výhoda tohoto přístupu je zároveň nevýhodou přístupu. Malé změny v datovém modelu nemusí nutně vést k tomu, že mnoho metod bude muset změnit své podpisy. Takže z hlediska údržby to funguje opravdu dobře. Pokud si pamatujete, že prezentační vrstva nemusí být nutně uživatelské rozhraní, může to být také webová služba. A pokud upravíte definici DataSet, možná proto, že přejmenováváte pole v databázi, pak upravujete smlouvu, kterou si webová služba předplácí. Jak si dokážete představit, může to vést k významným problémům. Tento scénář funguje dobře, pokud je prezentační vrstva pouze uživatelským rozhraním, ale pro rozhraní k externím systémům nebo komponentám budete chtít skrýt vnitřní fungování vaší aplikace a transformovat data na něco jiného, než je přímý klon vašeho datového modelu a budete chtít vytvořit objekty přenosu dat (DTO).
Datový tok pomocí objektového relačního mapování
Datový tok pomocí ADO.NET je velmi datově orientovaný přístup ke správě toku dat. Data a logika jsou diskrétní. Na druhém konci spektra je více objektově orientovaný přístup. Zde se vytvářejí třídy pro seskupování dat a chování. Cílem je definovat třídy, které napodobují data a chování nalezené v obchodní doméně, pro kterou byla aplikace vytvořena. Výsledek je často označován jako obchodní objekt. Kolekce obchodních objektů, které tvoří aplikaci, se nazývá doménový model. Někteří vývojáři tvrdí, že model bohaté domény je lepší pro navrhování složitější logiky. Takové tvrzení je těžké dokázat nebo vyvrátit. Jen vězte, že máte na výběr a je jen na vás, abyste si to vybrali.
Obrázek 8-6 ukazuje datový tok podobný obrázku 8-5 s tím rozdílem, že jste nyní přidali vrstvu relačního mapování objektů a nahradili objekty DataSet jinými datovými nosiči.
Nyní udělejte totéž krok za krokem jako dříve; představte si, že se někdo připojil k vašemu knihkupectví a objednal si tři knihy. Prezentační vrstva spravovala stav nákupního košíku. Zákazník je připraven provést objednávku a uvedl všechny potřebné údaje. Rozhodne se odeslat objednávku. Webová stránka promění všechna data na DTO, která obsahuje data pro jednu objednávku a se třemi řádky objednávek, vytvářející objekty podle potřeby. Webová stránka zobrazí tato data zpět uživateli ještě jednou, vázání dat řídí proti DTO pomocí ObjectDataSource v ASP.NET 2.0 a zeptá se Are you sure? Uživatel potvrdí volbu a DTO se odešle do logické vrstvy aplikace. Vrstva aplikační logiky transformuje DTO na obchodní objekt typu Order s vlastností obsahující tři objekty OrderLine. Metoda objednávky. Validate() je voláno, aby ověřilo objednávku a ověřilo, že všechna požadovaná pole mají hodnotu, a provede se kontrola, aby se zjistilo, zda uživatel nemá v nevyřízených složenkách více než R$ 1 000,00. Aby to bylo možné, objednávka zavolá Order.Customer.GetOutstandingBills(). Pokud je vše v pořádku, zavolá se metoda Order.Save(). Požadavek projde vrstvou objektového relačního mapování, kde jsou požadavek a řádky požadavku namapovány na DataTable v DataSet a DataSet je předán vrstvě pro přístup k datům, která se připojí k databázi a generuje příkazy vložení z informace v DataSetu. Existuje samozřejmě mnoho způsobů, jak může dojít k objektově-relačnímu mapování, ale ne všechny budou zahrnovat transformaci na DataSet. Někteří vytvoří příkaz insert přímo, ale k provedení tohoto příkazu budou stále používat vrstvu přístupu k datům.
Jak vidíte, dochází k určitým transformacím. Použití DTO je nezbytné, protože obchodní objekt implementuje chování a chování podléhá změnám. Chcete-li minimalizovat dopad těchto změn na prezentační vrstvu, musíte transformovat data z obchodního objektu na objekt přenosu dat. V Javě je objekt přenosu dat často označován jako objekt hodnoty.
Velkou výhodou práce s obchodními objekty je, že skutečně pomáhá organizovat váš kód. Pokud se podíváte zpět na složitou logiku, je obvykle velmi čitelná, protože je zde velmi málo instalatérského kódu. Nevýhodou je, že většina datových úložišť je stále relačních a mapování obchodních objektů na relační data může být poměrně složité.
služby založené na schématu
Právě jste viděli dva protiklady, pokud jde o řízení toku dat. Je možných mnoho variací. Běžná je varianta, kdy se jako základní datový nosič UI pro ukládání dat používá dataset, ale pro webové služby volané z jiných systémů se používají samostatná schémata (DTO). Aplikační vrstva transformuje relační data do předem definovaného schématu. Hlavní výhodou toho je, že jakákoli aplikace, která odkazuje na službu, nezávisí na žádném druhu vnitřní implementace komponenty. To umožňuje větší flexibilitu při verzování, zpětnou kompatibilitu rozhraní a možnost změnit implementaci komponenty bez změny rozhraní služby.
Samozřejmě můžete použít obchodní objekty ve webové aplikaci a obejít transformaci DTO, ale to obvykle funguje dobře, pouze pokud je aplikační logika implementována společně s webovou aplikací. Pamatujte, že pro volání Order.Save() budete potřebovat připojení k databázi. Zda je to žádoucí, je na vás a pravděpodobně na vašem řediteli bezpečnosti.