Filosofier for implementeringstilnærming
fossefall
Fossetilnærmingen for å implementere en applikasjon krever at en designer rådfører seg med en eller flere representanter for sluttbrukerorganisasjonen og skriver ned alle applikasjonens spesifikasjoner. Vanligvis kommer spesifikasjoner i et sett med funksjonelle dokumenter eller use cases, skrevet på en slik måte at sluttbrukeren enkelt kan lese og forstå dokumentene.
Sluttbrukeren signerer disse dokumentene, og dokumentene blir deretter samlet inn av det tekniske designteamet som designer applikasjonen, og lager ulike artefakter som klassemodelldiagrammer, tilstandsdiagrammer, aktivitetsdiagrammer og datamodeller. Målet med denne fasen er å skrive alt så detaljert at en utvikler ikke vil ha problemer med å lage den nødvendige koden. Det er en formell overlevering av designet til utviklingsteamet og til testteamet. Etter levering starter utviklingsteamet koding og testteamet bruker det tekniske designet i kombinasjon med brukssakene for å lage testcases og testscenarier.
Etter at utviklingsteamet er ferdig med kodingen, overleveres koden til testteamet. Testteamet utfører testene det har designet basert på kravene og detaljdesignet. Eventuelle problemer vil bli løst av utviklingsteamet. Når test- og fiksingsprosessen er fullført, leveres applikasjonen til sluttbrukeren for aksepttesting. Sluttbrukeren utfører en siste sjekk for å se om applikasjonen oppfyller de første kravene. Hvis godkjent, godkjenner han det ferdige produktet og prosjektet er fullført. Etter at utviklingsteamet er ferdig med kodingen, overleveres koden til testteamet.
Testteamet utfører testene det har designet basert på kravene og detaljdesignet. Eventuelle problemer vil bli løst av utviklingsteamet. Når test- og fiksingsprosessen er fullført, leveres applikasjonen til sluttbrukeren for aksepttesting. Sluttbrukeren utfører en siste sjekk for å se om applikasjonen oppfyller de første kravene. Hvis godkjent, godkjenner han det ferdige produktet og prosjektet er fullført. Etter at utviklingsteamet er ferdig med kodingen, overleveres koden til testteamet. Testteamet utfører testene det har designet basert på kravene og detaljdesignet.
Eventuelle problemer vil bli løst av utviklingsteamet. Når test- og fiksingsprosessen er fullført, leveres applikasjonen til sluttbrukeren for aksepttesting. Sluttbrukeren utfører en siste sjekk for å se om applikasjonen oppfyller de første kravene. Hvis godkjent, godkjenner han det ferdige produktet og prosjektet er fullført.
Sluttbrukeren utfører en siste sjekk for å se om applikasjonen oppfyller de første kravene. Hvis godkjent, godkjenner han det ferdige produktet og prosjektet er fullført. Sluttbrukeren utfører en siste sjekk for å se om applikasjonen oppfyller de første kravene. Hvis godkjent, godkjenner han det ferdige produktet og prosjektet er fullført.
Et prosjekt kan ha flere eller mindre faser når man bruker fossefallstilnærmingen, men nøkkelfunksjonen er en veldig formell start og slutt på hver fase, med veldig formelle leveranser.
Fordelen med fossefallstilnærmingen er at ansvaret til teamet som er ansvarlig for hver fase er større. Det er tydelig hva de skal levere, når de skal levere det, og hvem de skal levere det til. Ofte trenger ikke utviklingsteamet å samhandle med brukeren. Dette kan være svært nyttig når du outsourcer utvikling til et annet land.
Den største ulempen med fossefallstilnærmingen er at i et miljø hvor alt er organisert på en veldig formell måte, reduseres fleksibiliteten til å reagere på endringer. Selv flytting må organiseres. Svært få selskaper ser ut til å gjøre dette effektivt, noe som ofte resulterer i en betydelig økning i faste kostnader. For å administrere kostnadene til et prosjekt, utsetter noen selskaper til og med eventuelle endringer i kravene til den første applikasjonsleveringen, og leverer effektivt en applikasjon som ikke oppfyller sluttbrukerens behov.
smidig utvikling
Mange langvarige programvareutviklingsprosjekter gikk over budsjettet og leverte ikke produktet i tide. Premisset for den smidige programvareutviklingsfilosofien er å minimere risiko ved å utvikle programvare i korte tidsbokser, kalt iterasjoner, som vanligvis varer fra én til fire uker. Hver iterasjon er som sitt eget miniatyrprogramvareprosjekt og inkluderer alle oppgavene som er nødvendige for å frigjøre økningen av ny funksjonalitet: planlegging, kravanalyse, design, koding, testing og dokumentasjon. Selv om en iterasjon kanskje ikke legger til nok funksjonalitet til å garantere produktutgivelse, har et smidig programvareprosjekt som mål å kunne utgi ny programvare på slutten av hver iterasjon. På slutten av hver iterasjon revurderer teamet prosjektets prioriteringer.
Målet med smidig programvareutvikling er å oppnå kundetilfredshet gjennom rask og kontinuerlig levering av nyttig programvare; alltid sikte på å bygge det kunden trenger; velkommen, i stedet for å motsette seg, sene endringer i kravene; regelmessig tilpasse seg endrede omstendigheter; å ha et tett og daglig samarbeid mellom gründere og utviklere, der samtale ansikt til ansikt er den beste kommunikasjonsformen.
Hovedfordelen med smidig programvareutvikling er fleksibiliteten når det gjelder å håndtere endringer, alltid med mål om å levere i henhold til forretningsbehov. Ulempen er selvfølgelig en økning i kompleksiteten ved å administrere omfang, planlegging og budsjettering. En annen vanlig risiko er begrenset oppmerksomhet til (teknisk) dokumentasjon.
Inkrementell utvikling
Inkrementell programvareutvikling er en blanding av smidig og fosseutvikling. En applikasjon er designet, implementert og testet trinnvis slik at hvert trinn kan leveres til sluttbrukeren. Prosjektet er ikke fullført før siste inkrement er fullført. Den tar sikte på å forkorte kaskaden ved å definere mellomliggende trinn og bruke noen av fordelene med smidig utvikling. Basert på tilbakemelding mottatt på et tidligere inkrement, kan justeringer gjøres ved levering av neste inkrement. Det neste trinnet kan bestå av ny kode samt modifikasjoner av tidligere gitt kode.
Fordelen er at formaliteter forblir på plass, men endringsledelse blir enklere. Kostnaden for å teste og distribuere en applikasjon flere ganger vil være større enn å gjøre det bare én gang.
Program flytkontroll
Å velge en tilnærming til programflytkontroll er en veldig arkitektonisk oppgave. Målet er å lage en blåkopi av applikasjonen din der alt ser ut til å ha sin egen plass når du begynner å legge til funksjonalitet og kode. Hvis du noen gang har gjennomgått eller skrevet kode av høy kvalitet, forstår du dette prinsippet.
Arrangørkode
Det første trinnet i utformingen av programflyten er å organisere koden ved å etablere et sett med regler for å hjelpe med å lage en blåkopi, eller disposisjon, av applikasjonen. Vedlikehold, feilsøking og feilretting vil være enklere fordi koden er plassert på en logisk plassering. Når du har gjort grunnarbeidet, kan du velge en tilnærming for å implementere applikasjonens logikk.
Designmønstre bør spille en viktig rolle i utformingen av programflytkontroll. Gjennom årene har det blitt skrevet mye kode og mange løsninger har blitt utviklet for tilbakevendende problemer. Disse løsningene er lagt opp i designmønstre. Å bruke et designmønster på et vanlig programvaredesignproblem vil hjelpe deg med å lage løsninger som er lett gjenkjennelige og kan implementeres av jevnaldrende. Unike problemer vil fortsatt kreve unike løsninger, men du kan bruke designmønstre for å veilede deg i å løse dem.
Opprette prosjektet
lag
Det første trinnet er å vurdere logiske lag. Merk at lag ikke er det samme som lag, ofte forvirret eller til og med betraktet som det samme.
lag kontra lag
Lag handler om å lage grenser i koden din. Det øverste laget kan ha referanser til kode i lag under, men et lag kan aldri ha en referanse til kode i et lag over. Nivåer refererer til den fysiske fordelingen av nivåer på tvers av flere datamaskiner. For eksempel, i en tre-lags applikasjon, er brukergrensesnittet designet for å kjøre på en stasjonær datamaskin, applikasjonslogikken er designet for å kjøre på en applikasjonsserver, og databasen kjører på en databaseserver. med dedikerte data og koden i hver lag kan bestå av flere lag.
Figur 8-1: Grunnleggende tre-lags organisasjon
Lag refererer til nivåer av abstraksjon. Lagene vist i figur 8-1 gjelder for de fleste bruksområder. Disse nivåene blir også referert til som de tre hovedlagene og kan ha forskjellige andre navn. Som regel kan kode i presentasjonslaget kalle tjenester i applikasjonslogikklaget, men applikasjonslogikklaget må ikke kalle metoden i presentasjonslaget. Presentasjonslaget skal aldri kalle datatilgangslaget direkte, da dette ville omgå ansvaret implementert av applikasjonslogikklaget. Datatilgangslaget skal aldri kalle applikasjonslogikklaget.
Lag er bare en abstraksjon, og sannsynligvis den enkleste måten å implementere lag på er å lage mapper i prosjektet og legge til kode i den aktuelle mappen. En mer nyttig tilnærming ville være å plassere hvert lag i et separat prosjekt, og dermed lage separate sammenstillinger. Fordelen med å sette applikasjonslogikken din i en biblioteksammenstilling er at den lar deg lage enhetstester, ved å bruke Microsoft Visual Studio eller NUnit, for å teste logikken. Det skaper også fleksibilitet i valg av hvor hvert lag skal distribueres.
Fysiske lag
I en bedriftsapplikasjon vil du forvente å ha flere klienter for samme logikk. Det som faktisk gjør en applikasjon til en bedriftsapplikasjon er at den vil bli distribuert i tre lag: klient, applikasjonsserver og databaseserver. Microsoft Office Access-applikasjonen opprettet av bedriftens salgsavdeling, selv om den er svært viktig for salgsavdelingen, er ikke en bedriftsapplikasjon.
Merk at applikasjonslogikk og datatilgangslag ofte distribueres sammen på applikasjonsserveren. En del av utformingen av prosjektet er å velge om du vil få tilgang til applikasjonsserveren ved å bruke eksterne .NET- eller webtjenester. Uansett hva du velger, vil du legge til litt kode for enkel tilgang til eksterne tjenester i presentasjonslaget. Hvis du bruker webtjenester for å få tilgang til tjenester på applikasjonsserveren din, vil Visual Studio .NET gjøre jobben for deg og generere proxy-koden, som automatisk gir en implementering av det eksterne proxy-mønsteret.
Legge til mønstre i lag
De tre grunnleggende lagene gir en oversikt på høyt nivå. La oss legge til noen strukturelle mønstre for å skape en robust bedriftsarkitektur. Resultatet er vist i figur 8-2.
Fokuser på applikasjonslogikklaget. Figur 8-2 viser at tilgang til applikasjonslogikk bruker fasademønsteret. En fasade er et objekt som gir et forenklet grensesnitt til en større mengde kode, for eksempel et klassebibliotek. En fasade kan redusere ekstern kodeavhengighet på den indre funksjonen til et bibliotek fordi det meste av kode bruker fasaden, og dermed tillater mer fleksibilitet i systemutvikling. For å gjøre dette vil fasaden gi et grovkornet grensesnitt til en samling finkornede objekter.
beslutningsflyt
Programflytkontroll, også kjent som beslutningsflyt, gjelder hvordan du designer tjenestene i applikasjonslogikklaget ditt, eller, som du så i forrige avsnitt, hvordan du designer metodene i fasaden din.
Det er to måter å organisere tjenestene på:
- handlingsorientert
- statsdrevet
Handlingsorientert tilnærming
Ved å organisere tjenester basert på brukerhandlinger, implementerer du applikasjonslogikk ved å tilby tjenester, som hver håndterer en spesifikk forespørsel fra presentasjonslaget. Dette er også kjent som transaksjonsskriptmønsteret. Denne tilnærmingen er populær fordi den er enkel og ser veldig naturlig ut. Eksempler på metoder som følger denne tilnærmingen er BookStoreService.AddNewOrder(Order order) og BookStoreService.CancelOrder(int orderId).
Logikken som trengs for å utføre handlingen implementeres veldig sekvensielt i metoden, noe som gjør koden svært lesbar, men også vanskeligere å gjenbruke. Bruk av ekstra designmønstre, for eksempel bordmodulmønsteret, kan bidra til å øke gjenbrukbarheten.
Statsdrevet tilnærming
Det er også mulig å gjennomføre søknadens beslutningsflyt på en mye mer statsorientert måte. Tjenester som tilbys av applikasjonsserveren er mer generiske, for eksempel BookStoreService.SaveOrder(Ordreordre). Denne metoden vil undersøke statusen til bestillingen og bestemme om du vil legge til en ny bestilling eller kansellere en eksisterende bestilling.
Datastrukturprosjekter
Du må ta flere valg når du designer datastrukturene dine. Det første valget er datalagringsmekanismen, det andre er den tiltenkte bruken av dataene, og det tredje er versjonskrav. Det er tre måter å se på datastrukturdesign:
- Tjenestene tilbyr data; data er en refleksjon av relasjonsdatabasen.
- Data må kartlegges til objekter og tjenester gir tilgang til objekter.
- Dataene som tilbys av tjenester må være skjemabaserte.
Å velge en av de tre som grunnlag for din dataflytstruktur bør gjøres på et tidlig stadium av designprosessen. Mange bedrifter har en bedriftsretningslinje som pålegger ett av tre alternativer for alle prosjekter, men der det er mulig, bør du revurdere alternativene for hvert prosjekt, og velge den optimale tilnærmingen for det aktuelle prosjektet.
Velge en datalagringsmotor
Når du designer applikasjonen din, må du utvilsomt designe et slags datalager. Følgende lagre og former for datalagring er tilgjengelige:
- Ta opp
- app.config-filen
- xml-filer
- ren tekstfiler
- Database
- meldingskø
Hver butikk har sine egne unike egenskaper og kan skreddersys til spesifikke krav.
Designe dataflyten
Dataflyt ved hjelp av ADO.NET
Ved å implementere datasentriske tjenester i applikasjonslogikklaget, vil du designe dataflyten din ved å bruke ADO.NET. Klassebiblioteket .NET Framework tilbyr et omfattende applikasjonsprogrammeringsgrensesnitt (API) for å manipulere data i administrert kode. Referert til som ADO.NET, API kan finnes i System.Data navneområdet. Fullstendig separasjon av databærere og datalagre er en viktig designfunksjon i ADO.NET. Klasser som DataSet, DataTable og DataRow er designet for å lagre data, men har ingen kunnskap om hvor dataene kom fra. De anses som datakildeagnostiske. Et eget sett med klasser, som SqlConnection, SqlDataAdapter og SqlCommand, tar seg av å koble til en datakilde, hente data og fylle ut datasettet, datatabellen og dataraden. Disse klassene er plassert i undernavneområder som System.Data.Sql, System.Data.OleDB, System.Data.Oracle og så videre. Avhengig av hvilken datakilde du vil koble til, kan du bruke klasser i riktig navneområde, og avhengig av omfanget av produktet du bruker, vil du oppdage at disse klassene tilbyr mer eller mindre funksjonalitet.
Siden datasettet ikke er koblet til datakilden, kan det brukes ganske vellykket til å administrere dataflyten i en applikasjon. Figur 8-5 viser dataflyten når du gjør dette.
La oss ta en titt på dette prosjektet og forestille oss at noen har logget inn på bokhandelen din og bestilt tre bøker. Presentasjonslaget administrerte statusen til handlekurven. Kunden er klar til å legge inn bestillingen og har oppgitt alle nødvendige data. Han velger å sende ordre. Nettsiden transformerer alle dataene til et Datasett som inneholder to Datatabeller, en for bestilling og en for bestilling; setter inn en DataRow for ordren; og setter inn tre DataRows for ordrelinjene. Nettsiden viser deretter disse dataene tilbake til brukeren igjen, binder datakontroller mot datasettet og spør Er du sikker? Brukeren bekrefter forespørselen og den sendes til søknadens logiske lag. Applikasjonslogikklaget sjekker datasettet for å se om alle obligatoriske felt har en verdi og utfører en sjekk for å se om brukeren har mer enn 1000 US$. 00 på utestående regninger. Hvis alt går bra, sendes datasettet til datatilgangslaget, som kobles til databasen og genererer insert-setninger fra datasettinformasjonen.
Å bruke Datasettet på denne måten er en rask og effektiv måte å bygge en applikasjon på og bruke kraften til Framework Class Library og ASP.NETs evne til å binde data til ulike kontroller som GridView mot et DataSet. I stedet for å bruke enkle DataSet-objekter, kan du bruke Typed DataSet-objekter og forbedre kodeopplevelsen ved å implementere kode i presentasjonslaget så vel som applikasjonslogikklaget. Fordelen med denne tilnærmingen er også ulempen med tilnærmingen. Små endringer i datamodellen fører ikke nødvendigvis til at mange metoder må endre signaturer. Så vedlikeholdsmessig fungerer dette veldig bra. Hvis du husker at presentasjonslaget ikke nødvendigvis er et brukergrensesnitt, kan det også være en webtjeneste. Og hvis du endrer definisjonen av datasettet, kanskje fordi du gir nytt navn til et felt i databasen, endrer du kontrakten som nettjenesten abonnerer på. Som du kan forestille deg, kan dette føre til noen betydelige problemer. Dette scenariet fungerer bra hvis presentasjonslaget bare er et brukergrensesnitt, men for grensesnitt til eksterne systemer eller komponenter, vil du ønske å skjule den indre funksjonen til applikasjonen din og transformere data til noe annet enn en direkte klone av datamodellen og du vil lage dataoverføringsobjekter (DTOs).
Dataflyt ved bruk av objektrelasjonell kartlegging
Dataflyt ved bruk av ADO.NET er en veldig datasentrisk tilnærming til å administrere dataflyt. Data og logikk er diskrete. Den andre enden av spekteret tar en mer objektorientert tilnærming. Her opprettes klasser for å gruppere data og atferd. Målet er å definere klasser som etterligner dataene og atferden som finnes i forretningsdomenet som applikasjonen ble opprettet for. Resultatet omtales ofte som et forretningsobjekt. Samlingen av forretningsobjekter som utgjør applikasjonen kalles domenemodellen. Noen utviklere hevder at en rik domenemodell er bedre for å designe mer kompleks logikk. Det er vanskelig å bevise eller motbevise et slikt utsagn. Bare vit at du har et valg, og det er opp til deg å gjøre det.
Figur 8-6 viser en dataflyt som ligner på figur 8-5 , bortsett fra at du nå har lagt til objektrelasjonskartleggingslaget og erstattet DataSet-objektene med forskjellige databærere.
Gjør nå det samme steg for steg som før; se for deg at noen koblet til bokhandelen din og bestilte tre bøker. Presentasjonslaget administrerte statusen til handlekurven. Kunden er klar til å legge inn bestillingen og har oppgitt alle nødvendige data. Han velger å sende ordre. Nettsiden gjør alle dataene til en DTO, som inneholder data for én ordre og med tre ordrelinjer, og oppretter objektene etter behov. Nettsiden viser disse dataene tilbake til brukeren igjen, databinding kontrollerer mot DTO ved å bruke ObjectDataSource i ASP.NET 2.0 og spør Er du sikker? Brukeren bekrefter valget og DTO sendes til søknadens logiske lag. Applikasjonslogikklaget transformerer DTO til et forretningsobjekt av typen Order med en egenskap som inneholder tre OrderLine-objekter. Ordremetoden. Validate() kalles for å validere bestillingen og verifisere at alle obligatoriske felt har en verdi, og en sjekk blir utført for å identifisere om brukeren har mer enn R$ 1000,00 i ventende slipp. For å gjøre dette vil bestillingen kalle Order.Customer.GetOutstandingBills(). Hvis alt er bra, kalles Order.Save()-metoden. Forespørselen vil gå gjennom det relasjonelle kartleggingslaget for objekter, hvor forespørselen og radene i forespørselen blir tilordnet en DataTable i et datasett, og datasettet sendes til datatilgangslaget, som kobles til databasen og genererer insert-setninger fra informasjonen i datasettet. Det er selvfølgelig mange måter objektrelasjonell kartlegging kan skje på, men ikke alle vil inkludere transformasjon til et datasett. Noen vil opprette insert-setningen direkte, men fortsatt bruke datatilgangslaget for å utføre den setningen.
Som du kan se, skjer noen transformasjoner. Bruken av DTOer er nødvendig fordi et forretningsobjekt implementerer atferden og atferden kan endres. For å minimere effekten av disse endringene på presentasjonslaget, må du transformere dataene ut av forretningsobjektet og til et dataoverføringsobjekt. I Java blir dataoverføringsobjektet ofte referert til som verdiobjektet.
En stor fordel med å jobbe med forretningsobjekter er at det virkelig hjelper å organisere koden din. Hvis du ser tilbake på en kompleks logikk, er den vanligvis veldig lesbar fordi det er veldig lite rørleggerkode. Ulempen er at de fleste datalagre fortsatt er relasjonelle og kartlegging av forretningsobjekter til relasjonsdata kan bli ganske komplisert.
skjemabaserte tjenester
Du har nettopp sett to motsetninger når det gjelder å administrere dataflyten. Mange variasjoner er mulig. En vanlig er varianten der et datasett brukes som den grunnleggende databæreren til brukergrensesnittet for lagring av data, men separate skjemaer (DTOer) brukes for webtjenester kalt fra andre systemer. Applikasjonslaget transformerer relasjonsdata til et forhåndsdefinert skjema. Hovedfordelen med dette er at enhver applikasjon som refererer til tjenesten ikke er avhengig av noen form for intern implementering av komponenten. Dette gir mulighet for mer fleksibilitet i versjonering, bakoverkompatibilitet av grensesnitt, og muligheten til å endre komponentens implementering uten å endre tjenestens grensesnitt.
Selvfølgelig kan du bruke forretningsobjekter i webapplikasjonen og omgå DTO-transformasjonen, men dette fungerer vanligvis bare bra hvis applikasjonslogikken implementeres sammen med webapplikasjonen. Husk at for å ringe Order.Save() trenger du en databasetilkobling. Hvorvidt dette er ønskelig er opp til deg og sannsynligvis sikkerhetsdirektøren din.