Rakendamise lähenemisviisi filosoofiad
kose lähenemine
Rakenduse juurutamise juga-lähenemine nõuab, et disainer konsulteeriks ühe või mitme lõppkasutaja organisatsiooni esindajaga ja kirjutaks üles kõik rakenduse spetsifikatsioonid. Tavaliselt esitatakse spetsifikatsioonid funktsionaalsete dokumentide või kasutusjuhtumite komplektina, mis on kirjutatud nii, et lõppkasutaja saab dokumente hõlpsasti lugeda ja neist aru saada.
Lõppkasutaja allkirjastab need dokumendid ja seejärel kogub dokumendid kokku rakenduse kavandav tehniline projekteerimismeeskond, luues erinevaid artefakte, nagu klassimudeli diagrammid, olekudiagrammid, tegevusskeemid ja andmemudelid. Selle etapi eesmärk on kirjutada kõik nii detailselt, et arendajal ei tekiks probleeme vajaliku koodi loomisega. Toimub kujundus ametlik üleandmine arendusmeeskonnale ja testimismeeskonnale. Pärast tarnimist alustab arendusmeeskond kodeerimist ja testimismeeskond kasutab tehnilist disaini koos kasutusjuhtumitega, et luua testjuhtumeid ja testistsenaariume.
Kui arendusmeeskond on kodeerimise lõpetanud, antakse kood üle testmeeskonnale. Testimismeeskond viib läbi enda kavandatud testid nõuetest ja detailplaneeringust lähtuvalt. Kõik probleemid lahendab arendusmeeskond. Kui testimis- ja parandamisprotsess on lõppenud, saadetakse rakendus lõppkasutajale vastuvõtutestimiseks. Lõppkasutaja viib läbi viimase kontrolli, et näha, kas rakendus vastab esialgsetele nõuetele. Heakskiidu korral kinnitab ta valmistoote ja projekt on lõpetatud. Kui arendusmeeskond on kodeerimise lõpetanud, antakse kood üle testmeeskonnale.
Testimismeeskond viib läbi enda kavandatud testid nõuetest ja detailplaneeringust lähtuvalt. Kõik probleemid lahendab arendusmeeskond. Kui testimis- ja parandamisprotsess on lõppenud, saadetakse rakendus lõppkasutajale vastuvõtutestimiseks. Lõppkasutaja viib läbi viimase kontrolli, et näha, kas rakendus vastab esialgsetele nõuetele. Heakskiidu korral kinnitab ta valmistoote ja projekt on lõpetatud. Kui arendusmeeskond on kodeerimise lõpetanud, antakse kood üle testmeeskonnale. Testimismeeskond viib läbi enda kavandatud testid nõuetest ja detailplaneeringust lähtuvalt.
Kõik probleemid lahendab arendusmeeskond. Kui testimis- ja parandamisprotsess on lõppenud, saadetakse rakendus lõppkasutajale vastuvõtutestimiseks. Lõppkasutaja viib läbi viimase kontrolli, et näha, kas rakendus vastab esialgsetele nõuetele. Heakskiidu korral kinnitab ta valmistoote ja projekt on lõpetatud.
Lõppkasutaja viib läbi viimase kontrolli, et näha, kas rakendus vastab esialgsetele nõuetele. Heakskiidu korral kinnitab ta valmistoote ja projekt on lõpetatud. Lõppkasutaja viib läbi viimase kontrolli, et näha, kas rakendus vastab esialgsetele nõuetele. Heakskiidu korral kinnitab ta valmistoote ja projekt on lõpetatud.
Kose lähenemisviisi kasutamisel võib projektil olla rohkem või vähem etappe, kuid peamine omadus on iga etapi väga formaalne algus ja lõpp koos väga formaalsete tulemustega.
Kose lähenemise eeliseks on see, et iga faasi eest vastutava meeskonna vastutus on suurem. On selge, mida nad peavad tarnima, millal nad peavad seda tarnima ja kellele nad peavad seda toimetama. Sageli ei pea arendusmeeskond kasutajaga suhtlema. See võib olla väga kasulik, kui tellite arenduse teisest riigist sisse.
Kose lähenemise peamine puudus on see, et keskkonnas, kus kõik on korraldatud väga formaalselt, väheneb paindlikkus muutustele reageerida. Isegi kolimine tuleb organiseerida. Tundub, et väga vähesed ettevõtted teevad seda tõhusalt, mille tulemuseks on sageli üldkulude märkimisväärne suurenemine. Projekti kulude haldamiseks lükkavad mõned ettevõtted isegi nõuete muutmise edasi kuni rakenduse esmase tarnimiseni, pakkudes tõhusalt rakendust, mis ei vasta lõppkasutaja vajadustele.
vilgas areng
Paljud pikaajalised tarkvaraarendusprojektid ületasid eelarve ega tarninud toodet õigel ajal. Agiilse tarkvaraarenduse filosoofia eelduseks on riskide minimeerimine, arendades tarkvara lühikeste ajavahemike kaupa, mida nimetatakse iteratsioonideks, mis tavaliselt kestavad üks kuni neli nädalat. Iga iteratsioon on nagu oma miniatuurne tarkvaraprojekt ja sisaldab kõiki ülesandeid, mis on vajalikud uute funktsioonide juurdekasvu vabastamiseks: planeerimine, nõuete analüüs, disain, kodeerimine, testimine ja dokumentatsioon. Kuigi iteratsioon ei pruugi toote väljalaskmiseks piisavalt funktsioone lisada, on agiilse tarkvaraprojekti eesmärk võimaldada iga iteratsiooni lõpus väljastada uus tarkvara. Iga iteratsiooni lõpus hindab meeskond uuesti projekti prioriteedid.
Agiilse tarkvaraarenduse eesmärk on saavutada kliendi rahulolu läbi kasuliku tarkvara kiire ja pideva tarnimise; alati eesmärgiks ehitada see, mida klient vajab; tervitada nõuete hilinenud muudatusi, mitte olla vastu; kohaneda regulaarselt muutuvate oludega; teha tihedat ja igapäevast koostööd ettevõtjate ja arendajate vahel, milles silmast-silma vestlus on parim suhtlusvorm.
Agiilse tarkvaraarenduse peamiseks eeliseks on paindlikkus muutustega toimetulemisel, püüdes alati toimetada vastavalt ärivajadustele. Negatiivne külg on loomulikult ulatuse haldamise, planeerimise ja eelarvestamise keerukuse suurenemine. Teine levinud oht on piiratud tähelepanu (tehnilisele) dokumentatsioonile.
Järkjärguline areng
Täiendav tarkvaraarendus on segu agiilsest ja kosearendusest. Rakendus on kavandatud, juurutatud ja testitud järk-järgult, nii et iga juurdekasvu saab lõppkasutajale edastada. Projekti ei lõpetata enne, kui viimane osa on lõpetatud. Selle eesmärk on lühendada kaskaadi, määratledes vahepealsed juurdekasvud ja kasutades mõningaid agiilse arenduse eeliseid. Eelmise juurdekasvu kohta saadud tagasiside põhjal saab järgmise juurdekasvu tegemisel muudatusi teha. Järgmine juurdekasv võib koosneda nii uuest koodist kui ka varem antud koodi muudatustest.
Eeliseks on see, et formaalsused jäävad paika, kuid muudatuste juhtimine muutub lihtsamaks. Rakenduse mitmekordse testimise ja juurutamise kulud on suuremad kui ühekordse testimise ja juurutamise kulud.
Programmi voo juhtimine
Programmi voo juhtimise lähenemisviisi valimine on väga arhitektuurne ülesanne. Eesmärk on luua oma rakenduse plaan, kus pärast funktsionaalsuse ja koodi lisamist tundub, et kõigel on oma koht. Kui olete kunagi kvaliteetset koodi üle vaadanud või kirjutanud, saate sellest põhimõttest aru.
Korraldaja kood
Esimene samm programmivoo kujundamisel on koodi korraldamine, kehtestades reeglistiku, mis aitab luua rakenduse kavandi või kontuuri. Hooldus, silumine ja vigade parandamine on lihtsamad, kuna kood asub loogilises kohas. Kui olete eeltöö teinud, saate valida oma rakenduse loogika rakendamise lähenemisviisi.
Disainimustrid peaksid mängima olulist rolli programmivoo juhtimise kavandamisel. Aastate jooksul on kirjutatud palju koodi ja palju lahendusi on mõeldud korduvatele probleemidele. Need lahendused on välja toodud kujundusmustrites. Disainimustri rakendamine tavalisele tarkvarakujundusprobleemile aitab teil luua lahendusi, mis on kergesti äratuntavad ja mida teie kolleegid saavad rakendada. Ainulaadsed probleemid nõuavad endiselt ainulaadseid lahendusi, kuid saate nende lahendamiseks kasutada disainimustreid.
Projekti loomine
kihid
Esimene samm on kaaluda loogilisi kihte. Pange tähele, et kihid ei ole samad, mis kihid, sageli segaduses või neid peetakse isegi samadeks.
kihid versus kihid
Kihtide eesmärk on koodis piiride loomine. Ülemisel kihil võivad olla viited allolevate kihtide koodile, kuid kihil ei saa kunagi olla viidet ülaltoodud kihi koodile. Tasemed viitavad tasandite füüsilisele jaotusele mitme arvuti vahel. Näiteks kolmetasandilises rakenduses on kasutajaliides loodud töötama lauaarvutis, rakenduse loogika on loodud töötama rakendusserveris ja andmebaas töötab andmebaasiserveris. kiht võib koosneda mitmest kihist.
Joonis 8-1: Kolmetasandiline põhikorraldus
Kihid viitavad abstraktsioonitasemetele. Joonisel 8-1 näidatud kihid kehtivad enamiku rakenduste puhul. Neid tasemeid nimetatakse ka kolmeks peamiseks kihiks ja neil võib olla mitmeid muid nimetusi. Reeglina saab esitluskihi kood kutsuda rakenduste loogikakihi teenuseid, kuid rakenduse loogikakiht ei tohi kutsuda esitluskihi meetodit. Esitluskiht ei tohiks kunagi otse andmejuurdepääsukihti kutsuda, kuna see jätaks rakenduse loogikakihi rakendatud kohustustest mööda. Andmejuurdepääsukiht ei tohiks kunagi kutsuda rakenduse loogikakihti.
Kihid on lihtsalt abstraktsioon ja ilmselt kõige lihtsam viis kihtide rakendamiseks on luua oma projektis kaustu ja lisada kood vastavasse kausta. Kasulikum lähenemine oleks paigutada iga kiht eraldi projekti, luues nii eraldi koostud. Rakenduse loogika teegi komplekti lisamise eeliseks on see, et see võimaldab teil luua loogika testimiseks Microsoft Visual Studio või NUniti abil ühikuteste. See loob ka paindlikkuse iga kihi juurutamise koha valimisel.
Füüsilised kihid
Ettevõtterakenduses eeldate, et teil on sama loogika jaoks mitu klienti. Tegelikult teeb rakenduse ettevõtterakenduseks see, et seda juurutatakse kolmes kihis: klient, rakendusserver ja andmebaasiserver. Kuigi teie ettevõtte müügiosakonna loodud Microsoft Office Accessi rakendus on müügiosakonna jaoks väga oluline, ei ole see ettevõtte rakendus.
Pange tähele, et rakenduse loogika ja andmete juurdepääsukihid juurutatakse sageli rakendusserveris koos. Üks osa projekti kavandamisest on valida, kas pääsete juurde rakendusserverile kaug-.NET-i või veebiteenuste abil. Olenemata sellest, millise valite, lisate esitluskihi kaugteenustele hõlpsaks juurdepääsuks koodi. Kui kasutate oma rakendusserveris teenustele juurdepääsuks veebiteenuseid, teeb Visual Studio .NET teie eest töö ära ja genereerib puhverserveri koodi, pakkudes automaatselt kaugpuhverserveri mustri juurutamist.
Mustrite lisamine kihtidele
Kolm põhikihti annavad kõrgetasemelise ülevaate. Lisame mõned struktuurimustrid, et luua tugev ettevõttearhitektuur. Tulemus on näidatud joonisel 8-2.
Keskenduge rakenduse loogikakihile. Joonis 8-2 näitab, et rakenduse loogikale juurdepääsemisel kasutatakse fassaadimustrit. Fassaad on objekt, mis pakub lihtsustatud liidest suuremale koodikogule, näiteks klassiteegile. Fassaad võib vähendada välise koodi sõltuvust raamatukogu sisemisest tööst, kuna enamik koodidest kasutab fassaadi, võimaldades seega süsteemi arendamisel suuremat paindlikkust. Selleks annab fassaad jämedateralise liidese peeneteraliste objektide kogumile.
otsuste voog
Programmi voo juhtimine, tuntud ka kui otsustusvoog, puudutab seda, kuidas kujundate teenuseid oma rakenduse loogikakihis või, nagu nägite eelmises lõigus, kuidas kujundate meetodeid oma fassaadil.
Teenuste korraldamiseks on kaks lähenemisviisi:
- tegevusele orienteeritud
- riigi juhitud
Tegevusele orienteeritud lähenemine
Kasutajatoimingutel põhinevaid teenuseid korraldades rakendate rakendusloogikat, pakkudes teenuseid, millest igaüks käsitleb konkreetset esitluskihi päringut. Seda tuntakse ka tehingu skripti mustrina. See lähenemine on populaarne, kuna see on lihtne ja näeb välja väga loomulik. Seda lähenemisviisi järgivate meetodite näited on BookStoreService.AddNewOrder(Order order) ja BookStoreService.CancelOrder(int orderId).
Toimingu sooritamiseks vajalik loogika rakendatakse meetodi sees väga järjestikku, muutes koodi hästi loetavaks, kuid ka raskemini taaskasutatavaks. Täiendavate kujundusmustrite, näiteks tabelimooduli mustri kasutamine võib aidata suurendada korduvkasutatavust.
Riigipõhine lähenemine
Samuti on võimalik rakenduse otsuste voogu rakendada palju riigikesksemalt. Rakendusserveri pakutavad teenused on oma olemuselt üldisemad, näiteks BookStoreService.SaveOrder(Tellimistellimus). See meetod uurib tellimuse olekut ja otsustab, kas lisada uus tellimus või tühistada olemasolev tellimus.
Andmestruktuuri projektid
Andmestruktuuride kujundamisel peate tegema mitu valikut. Esimene valik on andmete salvestamise mehhanism, teine andmete kasutusotstarve ja kolmas versiooninõuded. Andmestruktuuri kujunduse vaatamiseks on kolm võimalust.
- Teenused pakuvad andmeid; andmed on relatsiooniandmebaasi peegeldus.
- Andmed peavad olema objektidega kaardistatud ja teenused tagavad juurdepääsu objektidele.
- Teenuste pakutavad andmed peavad olema skeemipõhised.
Andmevoostruktuuri aluseks peaks olema üks kolmest valikust, mis tuleks teha projekteerimisprotsessi varases staadiumis. Paljudel ettevõtetel on ettevõtte juhised, mis nõuavad kõigi projektide puhul ühte kolmest valikust, kuid võimaluse korral peaksite iga projekti valikud ümber hindama, valides antud projekti jaoks optimaalse lähenemisviisi.
Andmesalvestusmootori valimine
Rakenduse kujundamisel peate kahtlemata kujundama mingi andmesalve. Saadaval on järgmised andmehoidlad ja -vormid:
- Salvestus
- faili app.config
- xml failid
- lihtteksti failid
- Andmebaas
- sõnumite järjekord
Igal kauplusel on oma ainulaadsed omadused ja seda saab kohandada vastavalt konkreetsetele nõuetele.
Andmevoo kujundamine
Andmevoog ADO.NET-i abil
Rakenduse loogikakihis andmekesksete teenuste juurutamisel kujundate oma andmevoo ADO.NET-i abil. .NET Frameworki klassi teek pakub ulatuslikku rakenduste programmeerimisliidest (API) hallatud koodis andmetega manipuleerimiseks. API-d, millele viidatakse kui ADO.NET, leiate nimeruumist System.Data. Andmekandjate ja andmehoidlate täielik eraldamine on ADO.NETi oluline disainifunktsioon. Klassid, nagu DataSet, DataTable ja DataRow, on loodud andmete salvestamiseks, kuid ei tea, kust andmed pärinevad. Neid peetakse andmeallika agnostikuteks. Eraldi klasside komplekt, nagu SqlConnection, SqlDataAdapter ja SqlCommand, hoolitseb andmeallikaga ühenduse loomise, andmete toomise ning andmekomplekti, andmetabeli ja DataRow täitmise eest. Need klassid asuvad alamnimeruumides nagu System.Data.Sql, System.Data.OleDB, System.Data.Oracle ja nii edasi. Sõltuvalt sellest, millise andmeallikaga soovite ühenduse luua, saate klasse kasutada õiges nimeruumis ja olenevalt kasutatava toote ulatusest leiate, et need klassid pakuvad rohkem või vähem funktsioone.
Kuna DataSet pole andmeallikaga ühendatud, saab seda üsna edukalt kasutada andmevoo haldamiseks rakenduses. Joonis 8-5 näitab andmevoogu seda tehes.
Vaatame seda projekti ja kujutame ette, et keegi on teie raamatupoodi sisse loginud ja kolm raamatut tellinud. Esitluskiht haldas ostukorvi olekut. Klient on valmis tellimust esitama ja esitanud kõik vajalikud andmed. Ta valib tellimuse saatmise. Veebileht teisendab kõik andmed DataSet'iks, mis sisaldab kahte andmetabelit, üks tellimuse ja teine tellimuse jaoks; sisestab tellimusele DataRow; ja lisab tellimuse ridadele kolm andmerida. Seejärel kuvab veebileht need andmed kasutajale uuesti, sidudes andmejuhtelemendid DataSetiga ja küsides, kas olete kindel? Kasutaja kinnitab päringu ja see edastatakse rakenduse loogilisse kihti. Rakenduse loogikakiht kontrollib andmekogumit, et näha, kas kõigil nõutavatel väljadel on väärtus, ja kontrollib, kas kasutajal on rohkem kui 1000 US$. 00 tasumata arvetelt. Kui kõik läheb hästi, edastatakse DataSet andmetele juurdepääsukihile, mis loob ühenduse andmebaasiga ja genereerib andmekogumi teabest sisestuslaused.
Andmekomplekti kasutamine sellisel viisil on kiire ja tõhus viis rakenduse loomiseks ning Framework Class Library võimsuse ja ASP.NETi võime siduda andmeid erinevate juhtelementidega, näiteks GridView andmekomplektiga. Lihtsate DataSeti objektide kasutamise asemel saate kasutada Typed DataSet objekte ja parandada kodeerimiskogemust, rakendades koodi nii esitluskihis kui ka rakenduse loogikakihis. Selle lähenemisviisi eeliseks on ka lähenemisviisi puudus. Väikesed muudatused andmemudelis ei tähenda tingimata, et paljud meetodid peavad oma allkirju muutma. Nii et hoolduse osas töötab see tõesti hästi. Kui mäletate, et esitluskiht ei pruugi olla kasutajaliides, võib see olla ka veebiteenus. Ja kui muudate DataSeti definitsiooni, võib-olla seetõttu, et nimetate andmebaasis välja ümber, siis muudate lepingut, mille veebiteenus tellib. Nagu võite ette kujutada, võib see kaasa tuua olulisi probleeme. See stsenaarium toimib hästi, kui esitluskiht on lihtsalt kasutajaliides, kuid väliste süsteemide või komponentide liideste puhul peaksite peitma oma rakenduse sisemise töö ja muutma andmed millekski muuks kui teie andmemudeli otseseks klooniks. soovite luua andmeedastusobjekte (DTO).
Andmevoog objektide relatsioonilise kaardistamise abil
ADO.NET-i kasutav andmevoog on andmevoo haldamisel väga andmekeskne lähenemine. Andmed ja loogika on diskreetsed. Spektri teine ots on rohkem objektorienteeritud lähenemine. Siin luuakse klassid andmete ja käitumise rühmitamiseks. Eesmärk on määratleda klassid, mis jäljendavad andmeid ja käitumist, mis on leitud selles ärivaldkonnas, mille jaoks rakendus loodi. Tulemust nimetatakse sageli äriobjektiks. Rakenduse moodustavate äriobjektide kogumit nimetatakse domeenimudeliks. Mõned arendajad väidavad, et rikas domeenimudel sobib paremini keerukama loogika kujundamiseks. Sellist väidet on raske tõestada või ümber lükata. Lihtsalt teadke, et teil on valik ja see on teie otsustada.
Joonisel 8-6 on kujutatud andmevoogu, mis sarnaneb joonisega 8-5, välja arvatud nüüd, kui olete lisanud objektide relatsioonilise vastendamise kihi ja asendanud DataSeti objektid erinevate andmekandjatega.
Nüüd tehke sama samm-sammult nagu varem; kujutage ette, et keegi ühendas teie raamatupoega ja tellis kolm raamatut. Esitluskiht haldas ostukorvi olekut. Klient on valmis tellimust esitama ja esitanud kõik vajalikud andmed. Ta valib tellimuse saatmise. Veebileht muudab kõik andmed DTO-ks, säilitades andmed ühe tellimuse ja kolme tellimuse reaga, luues objekte vastavalt vajadusele. Veebileht kuvab need andmed kasutajale uuesti, andmete sidumine kontrollib DTO-d, kasutades ASP.NET 2.0 ObjectDataSource'i, ja küsib, kas olete kindel? Kasutaja kinnitab valiku ja DTO edastatakse rakenduse loogilisse kihti. Rakenduse loogikakiht teisendab DTO äriobjektiks Tellimuse tüüpi, mille atribuut sisaldab kolme OrderLine objekti. Tellimismeetod. Validate() kutsutakse tellimuse kinnitamiseks ja veendumaks, et kõigil kohustuslikel väljadel on väärtus, ning kontrollitakse, kas kasutajal on ootel sedeleid rohkem kui R$ 1000,00. Selleks kutsutakse tellimuses esile Order.Customer.GetOutstandingBills(). Kui kõik on korras, kutsutakse välja meetod Order.Save(). Päring läbib objektide relatsioonilise vastendamise kihi, kus päring ja päringu read vastendatakse andmekogumi andmetabelisse ning andmekogum edastatakse andmete juurdepääsukihile, mis loob ühenduse andmebaasiga ja genereerib Andmekomplektis olev teave. Muidugi on palju viise, kuidas objektide suhteline vastendamine toimuda, kuid mitte kõik neist ei hõlma andmekogumiks teisendamist. Mõned loovad lisalause otse, kuid kasutavad selle avalduse täitmiseks siiski andmete juurdepääsukihti.
Nagu näete, toimuvad mõned muutused. DTO-de kasutamine on vajalik, kuna äriobjekt rakendab käitumist ja käitumine võib muutuda. Nende muudatuste mõju esitluskihile minimeerimiseks peate muutma andmed äriobjektist välja andmeedastusobjektiks. Javas nimetatakse andmeedastusobjekti sageli väärtusobjektiks.
Äriobjektidega töötamise suur eelis on see, et see aitab tõesti teie koodi korrastada. Kui vaatate tagasi keerukale loogikale, on see tavaliselt hästi loetav, kuna torustiku koodi on väga vähe. Negatiivne külg on see, et enamik andmesalve on endiselt relatsioonilised ja äriobjektide vastendamine relatsiooniandmetega võib muutuda üsna keeruliseks.
skeemipõhised teenused
Andmevoo haldamisel nägite just kahte vastandit. Võimalikud on mitmed variatsioonid. Levinud on variant, kus andmete salvestamiseks kasutatakse kasutajaliidese põhiandmekandjana andmestikku, kuid teistest süsteemidest kutsutavate veebiteenuste jaoks kasutatakse eraldi skeeme (DTO). Rakenduskiht teisendab relatsiooniandmed eelmääratletud skeemiks. Selle peamine eelis on see, et ükski teenusele viitav rakendus ei sõltu komponendi ühestki sisemisest teostusest. See võimaldab suuremat paindlikkust versioonide loomisel, liideste tagasiühilduvust ja võimalust muuta komponendi teostust ilma teenuse liidest muutmata.
Loomulikult saab veebirakenduses kasutada äriobjekte ja DTO teisendusest mööda minna, kuid see toimib tavaliselt hästi ainult siis, kui rakenduse loogika on realiseeritud koos veebirakendusega. Pidage meeles, et Order.Save() kutsumiseks vajate andmebaasiühendust. See, kas see on soovitav, on teie ja tõenäoliselt teie turvadirektori otsustada.