Filozofie implementačného prístupu
vodopádový prístup
Vodopádový prístup k implementácii aplikácie vyžaduje, aby dizajnér konzultoval s jedným alebo viacerými zástupcami organizácie koncového používateľa a zapísal si všetky špecifikácie aplikácie. Špecifikácie sa zvyčajne dodávajú v súbore funkčných dokumentov alebo prípadov použitia napísaných takým spôsobom, že koncový používateľ môže dokumenty ľahko prečítať a porozumieť im.
Koncový používateľ tieto dokumenty podpíše a dokumenty potom zhromaždí tím technického dizajnu, ktorý navrhne aplikáciu a vytvorí rôzne artefakty, ako sú diagramy modelov tried, stavové diagramy, diagramy aktivít a dátové modely. Cieľom tejto fázy je napísať všetko tak podrobne, že vývojár nebude mať problém s vytvorením potrebného kódu. Prebieha formálne odovzdanie návrhu vývojovému tímu a testovaciemu tímu. Po doručení začne vývojový tím kódovať a testovací tím použije technický návrh v kombinácii s prípadmi použitia na vytvorenie testovacích prípadov a testovacích scenárov.
Keď vývojový tím dokončí kódovanie, kód sa odovzdá testovaciemu tímu. Testovací tím vykonáva testy, ktoré navrhol na základe požiadaviek a podrobného návrhu. Akékoľvek problémy vyrieši vývojový tím. Po dokončení procesu testovania a opravy je aplikácia doručená koncovému používateľovi na akceptačné testovanie. Koncový používateľ vykoná záverečnú kontrolu, aby zistil, či aplikácia spĺňa počiatočné požiadavky. V prípade schválenia schváli hotový výrobok a projekt je hotový. Keď vývojový tím dokončí kódovanie, kód sa odovzdá testovaciemu tímu.
Testovací tím vykonáva testy, ktoré navrhol na základe požiadaviek a podrobného návrhu. Akékoľvek problémy vyrieši vývojový tím. Po dokončení procesu testovania a opravy je aplikácia doručená koncovému používateľovi na akceptačné testovanie. Koncový používateľ vykoná záverečnú kontrolu, aby zistil, či aplikácia spĺňa počiatočné požiadavky. V prípade schválenia schváli hotový výrobok a projekt je hotový. Keď vývojový tím dokončí kódovanie, kód sa odovzdá testovaciemu tímu. Testovací tím vykonáva testy, ktoré navrhol na základe požiadaviek a podrobného návrhu.
Akékoľvek problémy vyrieši vývojový tím. Po dokončení procesu testovania a opravy je aplikácia doručená koncovému používateľovi na akceptačné testovanie. Koncový používateľ vykoná záverečnú kontrolu, aby zistil, či aplikácia spĺňa počiatočné požiadavky. V prípade schválenia schváli hotový výrobok a projekt je hotový.
Koncový používateľ vykoná záverečnú kontrolu, aby zistil, či aplikácia spĺňa počiatočné požiadavky. V prípade schválenia schváli hotový výrobok a projekt je hotový. Koncový používateľ vykoná záverečnú kontrolu, aby zistil, či aplikácia spĺňa počiatočné požiadavky. V prípade schválenia schváli hotový výrobok a projekt je hotový.
Projekt môže mať pri použití vodopádového prístupu viac alebo menej fáz, ale kľúčovou črtou je veľmi formálny začiatok a koniec každej fázy s veľmi formálnymi výstupmi.
Výhodou vodopádového prístupu je, že zodpovednosť tímu zodpovedného za každú fázu je väčšia. Je jasné, čo potrebujú dodať, kedy to musia doručiť a komu to musia doručiť. Vývojový tím často nebude musieť komunikovať s používateľom. To môže byť veľmi užitočné pri outsourcingu vývoja do inej krajiny.
Hlavnou nevýhodou vodopádového prístupu je, že v prostredí, kde je všetko organizované veľmi formálnym spôsobom, sa znižuje flexibilita reagovať na zmeny. Aj sťahovanie treba organizovať. Zdá sa, že veľmi málo spoločností to robí efektívne, čo často vedie k výraznému zvýšeniu režijných nákladov. Na riadenie nákladov na projekt niektoré spoločnosti dokonca odkladajú akékoľvek zmeny požiadaviek až do počiatočného dodania aplikácie, čím efektívne dodajú aplikáciu, ktorá nespĺňa potreby koncového používateľa.
agilný vývoj
Mnohé dlhotrvajúce projekty vývoja softvéru prekročili rozpočet a nedodali produkt včas. Predpokladom filozofie agilného vývoja softvéru je minimalizovať riziko vývojom softvéru v krátkych časových intervaloch, nazývaných iterácie, ktoré zvyčajne trvajú jeden až štyri týždne. Každá iterácia je ako svoj vlastný miniatúrny softvérový projekt a zahŕňa všetky úlohy potrebné na uvoľnenie prírastku novej funkcionality: plánovanie, analýza požiadaviek, dizajn, kódovanie, testovanie a dokumentácia. Hoci iterácia nemusí pridať dostatočnú funkcionalitu na zaručenie vydania produktu, cieľom agilného softvérového projektu je, aby bolo možné vydať nový softvér na konci každej iterácie. Na konci každej iterácie tím prehodnotí priority projektu.
Cieľom agilného vývoja softvéru je dosiahnuť spokojnosť zákazníka prostredníctvom rýchleho a nepretržitého dodávania užitočného softvéru; vždy s cieľom vybudovať to, čo zákazník potrebuje; neskoršie zmeny požiadaviek skôr privítať, než sa postaviť proti nim; pravidelne sa prispôsobovať meniacim sa okolnostiam; mať úzku a každodennú spoluprácu medzi podnikateľmi a vývojármi, v ktorej je najlepšou formou komunikácie osobný rozhovor.
Hlavnou výhodou agilného vývoja softvéru je flexibilita pri riešení zmien s cieľom vždy dodať podľa potrieb firmy. Nevýhodou je samozrejme zvýšená zložitosť riadenia rozsahu, plánovania a rozpočtovania. Ďalším častým rizikom je obmedzená pozornosť venovaná (technickej) dokumentácii.
Prírastkový rozvoj
Inkrementálny vývoj softvéru je kombináciou agilného a vodopádového vývoja. Aplikácia je navrhnutá, implementovaná a testovaná postupne, takže každý prírastok môže byť doručený koncovému používateľovi. Projekt sa nedokončí, kým sa nedokončí posledný prírastok. Jeho cieľom je skrátiť kaskádu definovaním prechodných prírastkov a využitím niektorých výhod agilného vývoja. Na základe spätnej väzby prijatej na predchádzajúci prírastok je možné vykonať úpravy pri doručovaní ďalšieho prírastku. Ďalší prírastok môže pozostávať z nového kódu, ako aj z úprav predtým poskytnutého kódu.
Výhodou je, že formality ostávajú na mieste, ale riadenie zmien sa stáva jednoduchším. Náklady na viacnásobné testovanie a nasadenie aplikácie budú vyššie ako na jednorazové testovanie.
Riadenie toku programu
Výber prístupu k riadeniu toku programu je veľmi architektonickou úlohou. Cieľom je vytvoriť plán vašej aplikácie, kde, keď začnete pridávať funkcie a kód, všetko bude mať svoje vlastné miesto. Ak ste niekedy recenzovali alebo písali kvalitný kód, rozumiete tomuto princípu.
Kód organizátora
Prvým krokom pri navrhovaní toku programu je zorganizovať kód vytvorením súboru pravidiel, ktoré pomôžu vytvoriť plán alebo náčrt aplikácie. Údržba, ladenie a oprava chýb bude jednoduchšia, pretože kód je umiestnený na logickom mieste. Po vykonaní základných prác si môžete zvoliť prístup k implementácii logiky vašej aplikácie.
Dizajnové vzory by mali zohrávať dôležitú úlohu pri navrhovaní riadenia toku programu. V priebehu rokov bolo napísaných veľa kódu a bolo navrhnutých mnoho riešení pre opakujúce sa problémy. Tieto riešenia sú usporiadané v dizajnových vzoroch. Použitie vzoru návrhu na bežný problém s návrhom softvéru vám pomôže vytvoriť riešenia, ktoré sú ľahko rozpoznateľné a môžu byť implementované vašimi kolegami. Jedinečné problémy budú stále vyžadovať jedinečné riešenia, ale pri ich riešení môžete použiť návrhové vzory.
Vytvorenie projektu
vrstvy
Prvým krokom je zvážiť logické vrstvy. Všimnite si, že vrstvy nie sú to isté ako vrstvy, často sú zamieňané alebo dokonca považované za rovnaké.
vrstvy verzus vrstvy
Vrstvy sú o vytváraní hraníc vo vašom kóde. Horná vrstva môže mať odkazy na kód vo vrstvách pod nimi, ale vrstva nikdy nemôže mať odkaz na kód vo vrstve vyššie. Vrstvy označujú fyzické rozloženie vrstiev na viacerých počítačoch. Napríklad v trojvrstvovej aplikácii je používateľské rozhranie navrhnuté tak, aby bežalo na stolnom počítači, aplikačná logika je navrhnutá tak, aby bežala na aplikačnom serveri a databáza beží na databázovom serveri. vrstva môže pozostávať z niekoľkých vrstiev.
Obrázok 8-1: Základná trojvrstvová organizácia
Vrstvy sa týkajú úrovní abstrakcie. Vrstvy zobrazené na obrázku 8-1 platia pre väčšinu aplikácií. Tieto úrovne sa tiež označujú ako tri hlavné vrstvy a môžu mať rôzne iné názvy. Kód v prezentačnej vrstve môže spravidla volať služby v aplikačnej logickej vrstve, ale aplikačná logická vrstva nesmie volať metódu v prezentačnej vrstve. Prezentačná vrstva by nikdy nemala priamo volať vrstvu prístupu k údajom, pretože by sa tým obchádzali povinnosti implementované vrstvou aplikačnej logiky. Vrstva prístupu k údajom by nikdy nemala volať vrstvu aplikačnej logiky.
Vrstvy sú len abstrakciou a pravdepodobne najjednoduchším spôsobom implementácie vrstiev je vytvorenie priečinkov v projekte a pridanie kódu do príslušného priečinka. Užitočnejším prístupom by bolo umiestniť každú vrstvu do samostatného projektu, čím by sa vytvorili samostatné zostavy. Výhodou umiestnenia logiky vašej aplikácie do zostavy knižnice je, že vám umožní vytvárať testy jednotiek pomocou Microsoft Visual Studio alebo NUnit na testovanie logiky. Vytvára tiež flexibilitu pri výbere miesta nasadenia každej vrstvy.
Fyzické vrstvy
V podnikovej aplikácii by ste očakávali, že budete mať viacero klientov pre rovnakú logiku. V skutočnosti to, čo robí aplikáciu podnikovou aplikáciou, je to, že bude nasadená v troch vrstvách: klient, aplikačný server a databázový server. Aplikácia Microsoft Office Access vytvorená obchodným oddelením vašej spoločnosti, hoci je pre obchodné oddelenie veľmi dôležitá, nie je podnikovou aplikáciou.
Všimnite si, že aplikačná logika a vrstvy prístupu k údajom sú často nasadené spoločne na aplikačnom serveri. Súčasťou návrhu projektu je výber, či pristupovať k aplikačnému serveru pomocou vzdialených .NET alebo webových služieb. Čokoľvek si vyberiete, pridáte nejaký kód na jednoduchý prístup k vzdialeným službám v prezentačnej vrstve. Ak na prístup k službám na svojom aplikačnom serveri používate webové služby, Visual Studio .NET urobí prácu za vás a vygeneruje kód proxy, pričom automaticky poskytne implementáciu vzoru vzdialeného proxy.
Pridávanie vzorov do vrstiev
Tri základné vrstvy poskytujú prehľad na vysokej úrovni. Pridajme niekoľko štrukturálnych vzorov na vytvorenie robustnej podnikovej architektúry. Výsledok je znázornený na obrázku 8-2.
Zamerajte sa na vrstvu aplikačnej logiky. Obrázok 8-2 ukazuje, že prístup k aplikačnej logike využíva vzor fasády. Fasáda je objekt, ktorý poskytuje zjednodušené rozhranie pre väčšiu časť kódu, ako je napríklad knižnica tried. Fasáda môže znížiť závislosti externého kódu na vnútornom fungovaní knižnice, pretože väčšina kódu používa fasádu, čo umožňuje väčšiu flexibilitu pri vývoji systému. Na tento účel bude fasáda poskytovať hrubozrnné rozhranie kolekcii jemnozrnných predmetov.
rozhodovací tok
Riadenie toku programu, známe aj ako tok rozhodovania, sa týka toho, ako navrhujete služby vo vrstve logiky aplikácie alebo, ako ste videli v predchádzajúcom odseku, ako navrhujete metódy vo vašej fasáde.
Existujú dva prístupy k organizácii vašich služieb:
- akcie zamerané
- štátom riadený
Akčný prístup
Organizovaním služieb na základe akcií používateľa implementujete aplikačnú logiku ponúkaním služieb, z ktorých každá spracováva špecifickú požiadavku z prezentačnej vrstvy. Toto je tiež známe ako vzor transakčného skriptu. Tento prístup je populárny, pretože je jednoduchý a vyzerá veľmi prirodzene. Príklady metód, ktoré sa riadia týmto prístupom, sú BookStoreService.AddNewOrder(Objednávka) a BookStoreService.CancelOrder(int orderId).
Logika potrebná na vykonanie akcie je v rámci metódy implementovaná veľmi sekvenčne, vďaka čomu je kód veľmi čitateľný, no zároveň je ťažšie znovu použiť. Použitie ďalších návrhových vzorov, ako je vzor modulu tabuľky, môže pomôcť zvýšiť opätovnú použiteľnosť.
Štátom riadený prístup
Je tiež možné implementovať rozhodovací tok aplikácie oveľa viac stavovo orientovaným spôsobom. Služby ponúkané aplikačným serverom sú všeobecnejšieho charakteru, napríklad BookStoreService.SaveOrder (Objednávka). Táto metóda preskúma stav objednávky a rozhodne, či pridať novú objednávku alebo zrušiť existujúcu objednávku.
Projekty dátových štruktúr
Pri navrhovaní dátových štruktúr musíte urobiť niekoľko možností. Prvou voľbou je mechanizmus ukladania údajov, druhou je zamýšľané použitie údajov a treťou sú požiadavky na verziu. Existujú tri spôsoby, ako sa pozrieť na návrhy dátových štruktúr:
- Služby ponúkajú údaje; údaje sú odrazom relačnej databázy.
- Dáta musia byť namapované na objekty a služby poskytujú prístup k objektom.
- Údaje ponúkané službami musia byť založené na schéme.
Výber jednej z troch možností ako základu pre vašu štruktúru toku údajov by sa mal vykonať v počiatočnej fáze procesu návrhu. Mnoho spoločností má firemnú smernicu, ktorá nariaďuje jednu z troch možností pre všetky projekty, ale ak je to možné, mali by ste prehodnotiť možnosti pre každý projekt a zvoliť optimálny prístup pre daný projekt.
Výber nástroja na ukladanie údajov
Pri navrhovaní vašej aplikácie budete nepochybne musieť navrhnúť nejaký druh úložiska údajov. K dispozícii sú nasledujúce úložiská a formy ukladania údajov:
- Záznam
- súbor app.config
- xml súbory
- obyčajné textové súbory
- Databáza
- radenie správ
Každý obchod má svoje vlastné jedinečné vlastnosti a môže byť prispôsobený špecifickým požiadavkám.
Navrhovanie dátového toku
Dátový tok pomocou ADO.NET
Implementáciou dátovo-centrických služieb vo vrstve aplikačnej logiky navrhnete svoj dátový tok pomocou ADO.NET. Knižnica tried .NET Framework poskytuje rozsiahle aplikačné programové rozhranie (API) na manipuláciu s údajmi v riadenom kóde. Rozhranie API, označované ako ADO.NET, možno nájsť v priestore názvov System.Data. Úplné oddelenie dátových nosičov a dátových úložísk je dôležitým dizajnovým prvkom ADO.NET. Triedy ako DataSet, DataTable a DataRow sú navrhnuté tak, aby uchovávali údaje, ale neuchovávali žiadne informácie o tom, odkiaľ údaje pochádzajú. Sú považovaní za agnostických zdrojov údajov. Samostatná množina tried, ako napríklad SqlConnection, SqlDataAdapter a SqlCommand, sa stará o pripojenie k zdroju údajov, získavanie údajov a vypĺňanie DataSet, DataTable a DataRow. Tieto triedy sa nachádzajú v podmenných priestoroch ako System.Data.Sql, System.Data.OleDB, System.Data.Oracle atď. V závislosti od toho, ku ktorému zdroju údajov sa chcete pripojiť, môžete použiť triedy v správnom priestore názvov a v závislosti od rozsahu produktu, ktorý používate, zistíte, že tieto triedy ponúkajú viac alebo menej funkcií.
Keďže DataSet nie je pripojený k zdroju údajov, dá sa celkom úspešne použiť na riadenie toku údajov v aplikácii. Obrázok 8-5 zobrazuje tok údajov pri tomto postupe.
Pozrime sa na tento projekt a predstavme si, že sa niekto prihlásil do vášho kníhkupectva a objednal si tri knihy. Prezentačná vrstva spravovala stav nákupného košíka. Zákazník je pripravený zadať objednávku a uviedol všetky potrebné údaje. Rozhodne sa poslať objednávku. Webová stránka transformuje všetky údaje do DataSet obsahujúceho dve DataTables, jednu pre objednávku a jednu pre objednávku; vloží DataRow pre objednávku; a vloží tri DataRows pre riadky objednávky. Webová stránka potom znova zobrazí tieto údaje používateľovi, spojí ovládacie prvky údajov so súborom údajov a spýta sa Ste si istý? Používateľ potvrdí požiadavku a odošle ju do logickej vrstvy aplikácie. Vrstva aplikačnej logiky skontroluje DataSet, aby zistila, či všetky povinné polia majú hodnotu, a vykoná kontrolu, aby zistila, či má používateľ viac ako 1000 US$. 00 na neuhradené účty. Ak všetko pôjde dobre, DataSet sa odovzdá vrstve prístupu k dátam, ktorá sa pripojí k databáze a vygeneruje príkazy na vloženie z informácií DataSet.
Použitie DataSet týmto spôsobom je rýchly a efektívny spôsob, ako zostaviť aplikáciu a využiť silu Framework Class Library a schopnosť ASP.NET spájať dáta s rôznymi ovládacími prvkami, ako je napríklad GridView oproti DataSet. Namiesto použitia jednoduchých objektov DataSet môžete použiť objekty Typed DataSet a zlepšiť zážitok z kódovania implementáciou kódu do prezentačnej vrstvy, ako aj do vrstvy aplikačnej logiky. Výhodou tohto prístupu je aj nevýhoda tohto prístupu. Malé zmeny v dátovom modeli nemusia nevyhnutne viesť k tomu, že mnohé metódy budú musieť zmeniť svoje podpisy. Takže z hľadiska údržby to funguje naozaj dobre. Ak si pamätáte, že prezentačná vrstva nemusí byť nevyhnutne používateľské rozhranie, môže to byť aj webová služba. A ak upravíte definíciu množiny údajov, možno preto, že premenúvate pole v databáze, upravujete zmluvu, ku ktorej sa webová služba prihlásila. Ako si viete predstaviť, môže to viesť k závažným problémom. Tento scenár funguje dobre, ak je prezentačná vrstva len používateľským rozhraním, ale v prípade rozhraní k externým systémom alebo komponentom budete chcieť skryť vnútorné fungovanie vašej aplikácie a transformovať údaje na niečo iné, než je priamy klon vášho dátového modelu a budete chcieť vytvoriť objekty prenosu údajov (DTO).
Dátový tok pomocou objektového relačného mapovania
Dátový tok pomocou ADO.NET je veľmi dátovo orientovaný prístup k riadeniu dátového toku. Dáta a logika sú diskrétne. Na druhom konci spektra je viac objektovo orientovaný prístup. Tu sa vytvárajú triedy na zoskupenie údajov a správania. Cieľom je definovať triedy, ktoré napodobňujú údaje a správanie nachádzajúce sa v obchodnej doméne, pre ktorú bola aplikácia vytvorená. Výsledok sa často označuje ako obchodný objekt. Kolekcia obchodných objektov, ktoré tvoria aplikáciu, sa nazýva doménový model. Niektorí vývojári tvrdia, že bohatý model domény je lepší na navrhovanie zložitejšej logiky. Takéto tvrdenie je ťažké dokázať alebo vyvrátiť. Len vedzte, že máte na výber a je len na vás, či si ho vyberiete.
Obrázok 8-6 zobrazuje dátový tok podobný ako na obrázku 8-5, ale teraz ste pridali vrstvu relačného mapovania objektov a nahradili objekty DataSet inými dátovými nosičmi.
Teraz urobte to isté krok za krokom ako predtým; predstavte si, že sa niekto pripojil k vášmu kníhkupectvu a objednal si tri knihy. Prezentačná vrstva spravovala stav nákupného košíka. Zákazník je pripravený zadať objednávku a uviedol všetky potrebné údaje. Rozhodne sa poslať objednávku. Webová stránka premení všetky údaje na DTO, uchováva údaje pre jednu objednávku a s tromi riadkami objednávok, čím sa objekty podľa potreby vytvoria. Webová stránka zobrazí tieto údaje späť používateľovi ešte raz, dátové väzby riadia voči DTO pomocou ObjectDataSource v ASP.NET 2.0 a spýta sa Ste si istý? Používateľ potvrdí voľbu a DTO sa odošle do logickej vrstvy aplikácie. Vrstva aplikačnej logiky transformuje DTO na obchodný objekt typu Order s vlastnosťou, ktorá obsahuje tri objekty OrderLine. Metóda objednávky. Validate() sa volá na overenie objednávky a overenie, že všetky povinné polia majú hodnotu, a vykoná sa kontrola, aby sa zistilo, či má používateľ v čakajúcich listoch viac ako R$ 1 000,00. Aby to bolo možné, objednávka zavolá Order.Customer.GetOutstandingBills(). Ak je všetko v poriadku, zavolá sa metóda Order.Save(). Požiadavka prejde cez vrstvu relačného mapovania objektov, kde sa požiadavka a riadky požiadavky namapujú na DataTable v množine údajov a množina údajov sa odovzdá vrstve prístupu k údajom, ktorá sa pripojí k databáze a vygeneruje príkazy vloženia z informácie v množine údajov. Existuje, samozrejme, mnoho spôsobov, ktorými môže dôjsť k objektovo-relačnému mapovaniu, ale nie všetky budú zahŕňať transformáciu na množinu údajov. Niektorí vytvoria príkaz vložiť priamo, ale na vykonanie tohto príkazu stále používajú vrstvu prístupu k údajom.
Ako vidíte, dochádza k určitým transformáciám. Použitie DTO je nevyhnutné, pretože obchodný objekt implementuje správanie a správanie sa môže zmeniť. Ak chcete minimalizovať vplyv týchto zmien na prezentačnú vrstvu, musíte transformovať údaje z obchodného objektu na objekt prenosu údajov. V jazyku Java sa objekt prenosu údajov často označuje ako objekt hodnoty.
Veľkou výhodou práce s obchodnými objektmi je, že skutočne pomáha organizovať váš kód. Ak sa pozriete späť na kúsok zložitej logiky, je zvyčajne veľmi čitateľný, pretože je tam veľmi málo inštalačného kódu. Nevýhodou je, že väčšina dátových úložísk je stále relačných a mapovanie obchodných objektov na relačné dáta môže byť pomerne zložité.
služby založené na schéme
Práve ste videli dva protiklady, pokiaľ ide o riadenie toku údajov. Je možných veľa variácií. Bežný je variant, v ktorom sa ako základný dátový nosič používateľského rozhrania na ukladanie údajov používa dátová množina, ale pre webové služby volané z iných systémov sa používajú samostatné schémy (DTO). Aplikačná vrstva transformuje relačné údaje do preddefinovanej schémy. Hlavnou výhodou tohto je, že akákoľvek aplikácia, ktorá odkazuje na službu, nezávisí od žiadneho druhu internej implementácie komponentu. To umožňuje väčšiu flexibilitu pri vytváraní verzií, spätnú kompatibilitu rozhraní a možnosť zmeniť implementáciu komponentu bez zmeny rozhrania služby.
Samozrejme, môžete použiť obchodné objekty vo webovej aplikácii a obísť transformáciu DTO, ale zvyčajne to funguje dobre len vtedy, ak je aplikačná logika implementovaná spolu s webovou aplikáciou. Pamätajte, že na volanie Order.Save() budete potrebovať pripojenie k databáze. Či je to žiaduce, je na vás a pravdepodobne na vašom riaditeľovi bezpečnosti.