Filozofije izvedbenega pristopa
Pristop s slapom
Slapni pristop k implementaciji aplikacije zahteva, da se oblikovalec posvetuje z enim ali več predstavniki organizacije končnega uporabnika in zapiše vse specifikacije aplikacije. Običajno so specifikacije v nizu funkcionalnih dokumentov ali primerov uporabe, napisanih tako, da lahko končni uporabnik zlahka prebere in razume dokumente.
Končni uporabnik podpiše te dokumente in dokumente nato zbere skupina za tehnično oblikovanje, ki oblikuje aplikacijo, pri čemer ustvari različne artefakte, kot so diagrami modelov razredov, diagrami stanj, diagrami dejavnosti in podatkovni modeli. Cilj te faze je napisati vse tako podrobno, da bo razvijalec brez težav ustvaril potrebno kodo. Obstaja uradna predaja zasnove razvojni ekipi in skupini za testiranje. Po dobavi razvojna skupina začne kodirati, skupina za testiranje pa uporabi tehnično zasnovo v kombinaciji s primeri uporabe za ustvarjanje testnih primerov in testnih scenarijev.
Ko razvojna ekipa konča kodiranje, se koda preda ekipi za testiranje. Ekipa za testiranje izvaja teste, ki jih je zasnovala na podlagi zahtev in podrobnega načrta. Vse težave bo odpravila razvojna ekipa. Ko je postopek testiranja in sanacije končan, se aplikacija preda končnemu uporabniku v sprejemno testiranje. Končni uporabnik izvede končno preverjanje, ali aplikacija ustreza začetnim zahtevam. Če je odobren, odobri končni izdelek in projekt je zaključen. Ko razvojna ekipa konča kodiranje, se koda preda ekipi za testiranje.
Ekipa za testiranje izvaja teste, ki jih je zasnovala na podlagi zahtev in podrobnega načrta. Vse težave bo odpravila razvojna ekipa. Ko je postopek testiranja in sanacije končan, se aplikacija preda končnemu uporabniku v sprejemno testiranje. Končni uporabnik izvede končno preverjanje, ali aplikacija ustreza začetnim zahtevam. Če je odobren, odobri končni izdelek in projekt je zaključen. Ko razvojna ekipa konča kodiranje, se koda preda ekipi za testiranje. Ekipa za testiranje izvaja teste, ki jih je zasnovala na podlagi zahtev in podrobnega načrta.
Vse težave bo odpravila razvojna ekipa. Ko je postopek testiranja in sanacije končan, se aplikacija preda končnemu uporabniku v sprejemno testiranje. Končni uporabnik izvede končno preverjanje, ali aplikacija ustreza začetnim zahtevam. Če je odobren, odobri končni izdelek in projekt je zaključen.
Končni uporabnik izvede končno preverjanje, ali aplikacija ustreza začetnim zahtevam. Če je odobren, odobri končni izdelek in projekt je zaključen. Končni uporabnik izvede končno preverjanje, ali aplikacija ustreza začetnim zahtevam. Če je odobren, odobri končni izdelek in projekt je zaključen.
Projekt ima lahko več ali manj faz pri uporabi slapovega pristopa, vendar je glavna značilnost zelo formalen začetek in konec vsake faze z zelo formalnimi rezultati.
Prednost slapnega pristopa je večja odgovornost ekipe, ki je odgovorna za vsako fazo. Jasno je, kaj morajo dostaviti, kdaj morajo dostaviti in komu morajo dostaviti. Pogosto razvojni ekipi ni treba komunicirati z uporabnikom. To je lahko zelo koristno pri zunanjem izvajanju razvoja v drugi državi.
Glavna pomanjkljivost pristopa slapa je, da se v okolju, kjer je vse organizirano na zelo formalen način, zmanjša prilagodljivost za odzivanje na spremembe. Tudi selitev je treba organizirati. Zdi se, da zelo malo podjetij to počne učinkovito, kar pogosto povzroči znatno povečanje režijskih stroškov. Za obvladovanje stroškov projekta nekatera podjetja celo odložijo morebitne spremembe zahtev do začetne dostave aplikacije, s čimer dejansko dostavijo aplikacijo, ki ne ustreza potrebam končnega uporabnika.
Agilen razvoj
Številni dolgoročni razvojni projekti programske opreme so presegli proračun in izdelka niso uspeli dostaviti pravočasno. Predpostavka filozofije agilnega razvoja programske opreme je zmanjšanje tveganja z razvojem programske opreme v kratkih časovnih okvirih, imenovanih iteracije, ki običajno trajajo od enega do štirih tednov. Vsaka ponovitev je kot lasten miniaturni projekt programske opreme in vključuje vse naloge, potrebne za izdajo novega prirastka funkcionalnosti: načrtovanje, analiza zahtev, načrtovanje, kodiranje, testiranje in dokumentacija. Medtem ko iteracija morda ne bo dodala dovolj funkcionalnosti, ki bi upravičila izdajo izdelka, je cilj projekta agilne programske opreme omogočiti izdajo nove programske opreme na koncu vsake iteracije. Na koncu vsake ponovitve ekipa ponovno oceni prednostne naloge projekta.
Cilj agilnega razvoja programske opreme je doseči zadovoljstvo strank s hitro in neprekinjeno dostavo uporabne programske opreme; vedno si prizadeva zgraditi tisto, kar stranka potrebuje; pozdravljajo, namesto da nasprotujejo, poznim spremembam zahtev; redno prilagajanje spreminjajočim se okoliščinam; tesno, vsakodnevno sodelovanje med podjetniki in razvijalci, pri katerem je pogovor iz oči v oči najboljša oblika komunikacije.
Glavna prednost agilnega razvoja programske opreme je prilagodljivost pri soočanju s spremembami, pri čemer vedno stremimo k zagotavljanju v skladu s poslovnimi potrebami. Slaba stran je seveda povečanje kompleksnosti upravljanja obsega, načrtovanja in proračuna. Drugo pogosto tveganje je omejena pozornost na (tehnično) dokumentacijo.
Postopni razvoj
Inkrementalni razvoj programske opreme je mešanica agilnega in slapnega razvoja. Aplikacija je zasnovana, implementirana in preizkušena postopoma, tako da se lahko vsak korak dostavi končnemu uporabniku. Projekt ni dokončan, dokler ni dokončan zadnji korak. Njegov namen je skrajšati slap z definiranjem vmesnih korakov in uporabo nekaterih prednosti agilnega razvoja. Na podlagi povratnih informacij, prejetih o prejšnjem prirastku, se lahko izvedejo prilagoditve pri dostavi naslednjega prirastka. Naslednji prirastek je lahko sestavljen iz nove kode kot tudi sprememb predhodno podane kode.
Prednost je, da formalnosti ostanejo na mestu, vendar postane upravljanje sprememb lažje. Stroški večkratnega testiranja in uvajanja aplikacije bodo višji kot če bi to naredili samo enkrat.
Nadzor poteka programa
Izbira pristopa k nadzoru poteka programa je zelo arhitekturna naloga. Cilj je ustvariti načrt vaše aplikacije, v kateri se zdi, da ima vse svoje mesto, ko začnete dodajati funkcionalnost in kodo. Če ste kdaj pregledali ali napisali visokokakovostno kodo, razumete to načelo
Organizacijski kodeks
Prvi korak pri oblikovanju toka programa je organiziranje kode, vzpostavitev nabora pravil, ki pomagajo pri ustvarjanju načrta ali orisa aplikacije. Vzdrževanje, odpravljanje napak in popravljanje napak bo lažje, ker se koda nahaja na enem logičnem mestu. Ko opravite temelje, lahko izberete pristop za implementacijo vaše logike aplikacije.
Načrtovalni vzorci bi morali imeti pomembno vlogo pri načrtovanju nadzora poteka programa. Z leti je bilo napisanega veliko kode in oblikovanih veliko rešitev za ponavljajoče se težave. Te rešitve so določene v vzorcih oblikovanja. Uporaba oblikovalskega vzorca za običajno težavo pri načrtovanju programske opreme vam bo pomagala ustvariti rešitve, ki so lahko prepoznavne in jih bodo vaši vrstniki lahko implementirali. Edinstveni problemi bodo še vedno zahtevali edinstvene rešitve, vendar lahko uporabite vzorce oblikovanja, ki vas bodo vodili pri njihovem reševanju.
Ustvarjanje projekta
Plasti
Prvi korak je upoštevati logične plasti. Upoštevajte, da plasti niso enake kot plasti, pogosto jih zamenjujejo ali celo obravnavajo kot enake.
Plasti proti slojem
Pri slojih gre za ustvarjanje meja v vaši kodi. Zgornja plast ima lahko sklice na kodo v nižjih slojih, vendar plast nikoli ne more imeti sklicevanja na kodo v višji plasti. Plastenje zadeva fizično porazdelitev slojev po več računalnikih. Na primer, v trinivojski aplikaciji je uporabniški vmesnik zasnovan tako, da deluje na namiznem računalniku, logika aplikacije je zasnovana tako, da deluje na aplikacijskem strežniku, zbirka podatkov pa deluje na strežniku podatkovne baze. vsaka plast je lahko sestavljena iz več plasti.
Slika 8-1: Osnovna trinivojska organizacija
Plasti se nanašajo na ravni abstrakcije. Plasti, prikazane na sliki 8-1, veljajo za večino aplikacij. Te ravni se imenujejo tudi tri glavne plasti in imajo lahko več drugih imen. Koda v predstavitveni plasti praviloma lahko kliče storitve v aplikacijski logični plasti, vendar aplikacijska logična plast ne sme klicati metode v predstavitveni plasti. Predstavitveni sloj nikoli ne bi smel neposredno klicati sloja za dostop do podatkov, saj bi to zaobšlo odgovornosti, ki jih izvaja sloj aplikacijske logike. Plast dostopa do podatkov nikoli ne sme klicati plasti aplikacijske logike.
Sloji so samo abstrakcija in verjetno je najlažji način za implementacijo slojev ustvariti mape v vašem projektu in dodati kodo v ustrezno mapo. Uporabnejši pristop bi bil, če bi vsako plast postavili v ločen projekt in tako ustvarili ločene sklope. Prednost umestitve vaše logike aplikacije v sklop knjižnice je, da vam omogoča ustvarjanje testov enote z uporabo Microsoft Visual Studio ali NUnit, da preizkusite logiko. Prav tako ustvarja prilagodljivost pri izbiri, kje namestiti posamezno plast.
Fizične plasti
V aplikaciji podjetja bi morali pričakovati, da boste imeli več odjemalcev za isto logiko. Pravzaprav je aplikacija podjetniška aplikacija to, da bo nameščena v treh plasteh: odjemalec, aplikacijski strežnik in strežnik baz podatkov. Aplikacija Microsoft Office Access, ki jo je ustvaril prodajni oddelek vašega podjetja, ni poslovna aplikacija, čeprav je zelo pomembna za prodajni oddelek.
Upoštevajte, da sta aplikacijska logika in plasti dostopa do podatkov pogosto razporejeni skupaj na aplikacijskem strežniku. Del načrtovanja projekta je izbira, ali želite dostopati do aplikacijskega strežnika z uporabo .NET ali spletnih oddaljenih storitev.Ne glede na vašo izbiro boste dodali nekaj kode za enostaven dostop do oddaljenih storitev v predstavitveni plasti. Če uporabljate spletne storitve za dostop do storitev na vašem aplikacijskem strežniku, Visual Studio .NET opravi delo namesto vas in generira kodo proxy, ki samodejno zagotovi izvedbo vzorca oddaljenega proxyja.
Dodajanje vzorcev v plasti
Trije osnovni sloji zagotavljajo pregled na visoki ravni. Dodajmo nekaj strukturnih vzorcev, da ustvarimo robustno arhitekturo podjetja. Rezultat je prikazan na sliki 8-2.
Osredotočite se na plast aplikacijske logike. Slika 8-2 prikazuje, da dostop do logike aplikacije poteka z uporabo vzorca fasade. Fasada je objekt, ki zagotavlja poenostavljen vmesnik za večji del kode, kot je knjižnica razredov. Fasada lahko zmanjša odvisnost zunanje kode od notranjega delovanja knjižnice, ker večina kode uporablja fasado, kar omogoča večjo prilagodljivost pri razvoju sistema. Da bi to naredili, bo fasada zagotovila grobo zrnat vmesnik za zbirko drobnozrnatih predmetov.
Potek odločanja
Nadzor poteka programa, znan tudi kot tok odločanja, se nanaša na to, kako načrtujete storitve v logični plasti aplikacije ali, kot ste videli v prejšnjem odstavku, kako načrtujete metode v svoji fasadi.
Obstajata dva pristopa k organizaciji vaših storitev:
- Akcijsko usmerjen
- Državniško usmerjena
Akcijski pristop
Z organiziranjem storitev, ki temeljijo na uporabniških dejanjih, izvajate logiko aplikacije s ponudbo storitev, od katerih vsaka obravnava posebno zahtevo iz predstavitvene plasti. To je znano tudi kot vzorec transakcijskega skripta. Ta pristop je priljubljen, ker je preprost in deluje zelo naravno. Primeri metod, ki sledijo temu pristopu, so BookStoreService.AddNewOrder(Order order) in BookStoreService.CancelOrder(int orderId).
Logika, ki je potrebna za izvedbo dejanja, je znotraj metode implementirana zelo zaporedno, zaradi česar je zelo berljiva, a tudi težje ponovno uporabiti kodo. Uporaba dodatnih vzorcev oblikovanja, kot je vzorec modula tabele, lahko pomaga povečati ponovno uporabnost.
Državno usmerjen pristop
Možno je tudi implementirati tok odločanja v aplikaciji na način, ki je veliko bolj usmerjen v stanje. Storitve, ki jih ponuja aplikacijski strežnik, so bolj splošne narave, na primer BookStoreService.SaveOrder(Order order). Ta metoda bo pregledala status naročila in se odločila, ali dodati novo naročilo ali preklicati obstoječe naročilo.
Projekti podatkovne strukture
Pri načrtovanju podatkovnih struktur morate sprejeti več odločitev. Prva izbira je mehanizem za shranjevanje podatkov, druga je predvidena uporaba podatkov, tretja pa zahteve glede različic. Obstajajo trije načini za ogled zasnov strukture podatkov:
- Storitve ponujajo podatke; podatki so odraz relacijske baze podatkov.
- Podatki morajo biti preslikani v objekte, storitve pa omogočajo dostop do objektov.
- Podatki, ki jih ponujajo storitve, morajo temeljiti na shemi.
Izbira enega od treh kot podlage za vašo strukturo toka podatkov bi morala biti narejena v zgodnji fazi procesa načrtovanja. Številna podjetja imajo politiko podjetja, ki določa eno od treh možnosti za vse projekte, vendar bi morali, ko je to mogoče, ponovno oceniti možnosti za vsak projekt in izbrati idealen pristop za zadevni projekt.
Izbira mehanizma za shranjevanje podatkov
Ko načrtujete svojo aplikacijo, boste nedvomno morali oblikovati neko vrsto shranjevanja podatkov. Na voljo so naslednje shrambe in oblike shranjevanja podatkov:
- Zapis
- datoteko app.config
- datoteke XML
- datoteke z navadnim besedilom
- Baza podatkov
- Čakalna vrsta sporočil
Vsaka trgovina ima svoje edinstvene značilnosti in jo je mogoče prilagoditi posebnim zahtevam.
Oblikovanje pretoka podatkov
Pretok podatkov z uporabo ADO.NET
Pri izvajanju storitev, osredotočenih na podatke, v logičnem sloju aplikacije boste načrtovali pretok podatkov z uporabo ADO.NET. Knjižnica razredov .NET Framework ponuja obsežen vmesnik za programiranje aplikacij (API) za manipulacijo podatkov v upravljani kodi. API, imenovan ADO.NET, je mogoče najti v imenskem prostoru System.Data. Popolna ločitev medijev in podatkovnih shramb je pomembna konstrukcijska značilnost ADO.NET. Razredi, kot so DataSet, DataTable in DataRow, so zasnovani za shranjevanje podatkov, vendar ne ohranijo nobenega znanja o tem, od kod prihajajo podatki. Veljajo za agnostike podatkovnega vira. Ločen nabor razredov, kot so SqlConnection, SqlDataAdapter in SqlCommand, poskrbi za povezovanje z virom podatkov, pridobivanje podatkov in zapolnitev DataSet, DataTable in DataRow. Ti razredi se nahajajo v podimenskih prostorih, kot so System.Data.Sql, System.Data.OleDB, System.Data.Oracle itd. Glede na vir podatkov, s katerim se želite povezati, lahko uporabite razrede v pravilnem imenskem prostoru in glede na obseg izdelka, ki ga uporabljate, boste ugotovili, da ti razredi ponujajo več ali manj funkcionalnosti.
Ker DataSet ni povezan z virom podatkov, ga je mogoče precej uspešno uporabiti za upravljanje pretoka podatkov v aplikaciji. Slika 8-5 prikazuje pretok podatkov pri tem.
Oglejmo si ta projekt in si predstavljajmo, da se je nekdo prijavil v vašo knjigarno in naročil tri knjige. Predstavitveni sloj je upravljal stanje nakupovalnega vozička. Stranka je pripravljena na oddajo naročila in je posredovala vse potrebne podatke. Izbere pošiljanje naročila. Spletna stran pretvori vse podatke v DataSet, ki vsebuje dve podatkovni tabeli, eno za naročilo in eno za naročilo; vstavi DataRow za zahtevo; in vstavi tri DataRows za vrstice naročila. Spletna stran nato te podatke ponovno prikaže uporabniku, nadzoruje vezavo podatkov na DataSet in vpraša Ali ste prepričani? Uporabnik potrdi zahtevo in ta se odda v logični sloj aplikacije. Logična plast aplikacije preveri DataSet, ali imajo vsa zahtevana polja vrednost, in izvede preverjanje, ali ima uporabnik več kot US$ 1000. 00 za neporavnane račune. Če je vse v redu, se DataSet posreduje sloju za dostop do podatkov, ki se poveže z bazo podatkov in ustvari navodila za vstavljanje na podlagi podatkov DataSet.
Uporaba DataSeta na ta način je hiter in učinkovit način za ustvarjanje aplikacije in uporabo moči Framework Class Library in zmožnosti ASP.NET za vezavo podatkov na več kontrolnikov, kot je GridView proti DataSet. Namesto uporabe preprostih objektov DataSet lahko uporabite objekte Typed DataSet in izboljšate izkušnjo kodiranja z implementacijo kode v predstavitveni plasti kot tudi v logični plasti aplikacije. Prednost tega pristopa je hkrati tudi slabost pristopa. Majhne spremembe podatkovnega modela ne vodijo nujno do tega, da bi morale mnoge metode spremeniti svoje podpise. Kar zadeva vzdrževanje, to deluje zelo dobro. Če se spomnite, da predstavitveni sloj ni nujno uporabniški vmesnik, lahko je tudi spletna storitev. In če spremenite definicijo DataSet, morda zato, ker preimenujete polje v zbirki podatkov, potem spremenite pogodbo, ki jamči za Kot si lahko predstavljate, lahko to privede do precejšnjih težav. Ta scenarij dobro deluje, če je predstavitvena plast samo uporabniški vmesnik, toda za vmesnike do zunanjih sistemov ali komponent boste želeli skriti notranje delovanje vaše aplikacije in podatke pretvoriti v nekaj drugega kot neposredni klon vašega podatkovnega modela in boste želeli ustvariti objekte za prenos podatkov (DTO).
Pretok podatkov z uporabo relacijskega preslikave objektov
Pretok podatkov z uporabo ADO.NET je zelo podatkovno osredotočen pristop k upravljanju pretoka podatkov. Podatki in logika so diskretni. Druga stran spektra je bolj objektno usmerjen pristop. Tukaj so ustvarjeni razredi za združevanje podatkov in vedenja. Cilj je definirati razrede, ki posnemajo podatke in vedenje v poslovni domeni, za katero je bila aplikacija ustvarjena. Rezultat se pogosto imenuje poslovni objekt. Zbirka poslovnih objektov, ki sestavljajo aplikacijo, se imenuje domenski model. Nekateri razvijalci trdijo, da je model bogate domene boljši za oblikovanje kompleksnejše logike. Takšno trditev je težko dokazati ali ovreči. Samo vedi, da imaš izbiro in da je na tebi, da jo narediš.
Slika 8-6 prikazuje tok podatkov, podoben sliki 8-5, le da ste zdaj dodali plast objektno-relacijskega preslikave in zamenjali objekte DataSet z različnimi nosilci podatkov.
Zdaj naredite enako korak za korakom kot prej; Predstavljajte si, da se je nekdo prijavil v vašo knjigarno in naročil tri knjige. Predstavitveni sloj je upravljal stanje nakupovalnega vozička. Stranka je pripravljena na oddajo naročila in je posredovala vse potrebne podatke. Izbere pošiljanje naročila. Spletna stran preoblikuje vse podatke v DTO, ki vsebuje podatke za eno naročilo in s tremi vrsticami naročil, pri čemer po potrebi ustvari predmete. Spletna stran ponovno prikaže te podatke uporabniku, nadzor vezave podatkov proti DTO z uporabo ObjectDataSource v ASP.NET 2.0 in vpraša Ali ste prepričani? Uporabnik potrdi izbiro in DTO se predloži v logično plast aplikacije. Logična plast aplikacije pretvori DTO v poslovni objekt tipa Order z lastnostjo, da vsebuje tri objekte OrderLine. Metoda naročila. Validate() se kliče za potrditev naročila in preverjanje, ali imajo vsa obvezna polja vrednost, in preveri se, ali ima uporabnik več kot R$ 1.000,00 neporavnanih računov. Za to bo naročilo poklicalo Order.Customer.GetOutstandingBills(). Če je vse v redu, se pokliče metoda Order.Save(). Vrstni red bo predložen sloju relacijskega preslikave objektov, kjer se naročilo in vrstice naročila preslikajo v DataTable v DataSet, DataSet pa se posreduje sloju za dostop do podatkov, ki se poveže z bazo podatkov in ustvari navodila za vstavljanje iz informacij v DataSet. Seveda obstaja veliko načinov, na katere lahko pride do objektno-relacijskega preslikave, vendar vsi ne bodo vključevali transformacije v DataSet. Nekateri bodo neposredno ustvarili stavke vstavljanja, vendar bodo še vedno uporabljali sloj dostopa do podatkov za izvedbo tega stavka.
Kot lahko vidite, pride do nekaterih preobrazb. Uporaba DTO-jev je potrebna, ker poslovni objekt izvaja vedenje, vedenje pa se lahko spremeni. Če želite zmanjšati vpliv teh sprememb na predstavitveni sloj, morate podatke preoblikovati iz poslovnega objekta v objekt za prenos podatkov. V Javi se objekt za prenos podatkov običajno imenuje vrednostni objekt.
Velika prednost dela s poslovnimi objekti je, da resnično pomaga organizirati vašo kodo. Če pogledate nazaj na kos zapletene logike, je običajno zelo berljiv, ker je zelo malo vodovodne kode. Slaba stran je, da je večina podatkovnih shramb še vedno relacijskih in preslikava poslovnih objektov v relacijske podatke lahko postane precej zapletena.
Storitve, ki temeljijo na shemi
Pravkar ste videli dve nasprotji, ko gre za upravljanje pretoka podatkov. Možne so številne različice. Pogosta je različica, pri kateri se nabor podatkov uporablja kot osnovna podatkovna podpora uporabniškega vmesnika za shranjevanje podatkov, vendar se za spletne storitve, ki se kličejo iz drugih sistemov, uporabljajo ločene sheme (DTO). Aplikacijska plast pretvori relacijske podatke v vnaprej določeno shemo. Glavna prednost tega je, da nobena aplikacija, ki se sklicuje na storitev, ni odvisna od nobene vrste notranje implementacije komponente. To omogoča večjo prilagodljivost pri urejanju različic, povratno združljivost vmesnikov in možnost spreminjanja izvedbe komponente brez spreminjanja vmesnika storitve.
Seveda lahko uporabite poslovne objekte v spletni aplikaciji in obidete transformacijo DTO, vendar to na splošno deluje dobro le, če je logika aplikacije implementirana skupaj s spletno aplikacijo. Ne pozabite, da boste za klic Order.Save() potrebovali povezava z bazo podatkov. Ali je to zaželeno, je odvisno od vas in verjetno od vašega varnostnega direktorja.