Siden starten har J2EE (Java 2 Platform, Enterprise Edition) forenklet applikasjonskonstruksjonen i Java. Etter hvert som J2EE blir bredere adoptert, skjønner utviklere imidlertid behovet for definerte tilnærminger som både forenkler og standardiserer applikasjonsbygging. Du kan begynne å nå dette målet ved å standardisere applikasjonens arkitektoniske lag.
Det arkitektoniske laget innkapsler generelt applikasjonens tekniske kompleksiteter uavhengig av forretningslogikken, og gir dermed en løs kobling mellom forretningsfunksjonaliteten og den underliggende tekniske infrastrukturen. I denne artikkelen forklarer jeg en fremvoksende metode for å bygge applikasjonsarkitekturen for J2EE-prosjekter - en som benytter designmønstre for å gi standardisering og enkelhet som god arkitektur krever.
Applikasjonsarkitektur og J2EE
J2EE er en flott infrastrukturteknologi. Det gir en enhetlig standard for teknologiestakens oppgaver på lavere nivå, for eksempel databasekommunikasjon eller applikasjonsdistribusjon. J2EE leder imidlertid ikke utviklere til å bygge vellykkede applikasjoner. J2EEs skapere, som så ned i teknologibakken, lurte på: "Hvordan kan vi standardisere disse API-ene?" De burde ha sett opp applikasjonsutviklerne og spurt: "Hvordan kan jeg gi utviklerne byggesteinene de trenger for å fokusere på forretningsapplikasjonen?"
Når man begynner på et nytt J2EE-prosjekt, spør noen teammedlemmer ofte: "Hvis J2EE i seg selv er en arkitektur, hvorfor trenger vi mer?" Mange utviklere mente den misforståelsen i J2EEs tidlige dager, men erfarne J2EE-utviklere forstår at J2EE ikke gir applikasjonsarkitekturen som er nødvendig for å levere applikasjoner av høy kvalitet. Disse utviklerne bruker ofte designmønstre for å fylle gapet.
Design mønstre
I programmering lar designmønstre deg utnytte utviklerfellesskapets kollektive erfaring ved å dele problemer og løsninger som kommer alle til gode. Et designmønster må fange opp problemets definisjon og kontekst, en mulig løsning og løsningens konsekvenser.
I forbindelse med J2EE-applikasjonsarkitektur faller designmønstre i to kategorier: generelle programvareutviklingsmønstre og de mønstrene som identifiserer spesifikke J2EE-utfordringer. J2EE-spesifikke designmønstre identifiserer det minimale settet med kjente problemer som en solid applikasjonsarkitektur skal løse. Den tidligere gruppen, programvareutviklingsmønstre som ikke er spesifikke for J2EE, viser seg like kraftig - ikke for å identifisere problemer, men for å veilede arkitekturkonstruksjon.
La oss undersøke hvert område mer detaljert.
J2EE designmønstre
J2EE designmønstre har utviklet seg de siste årene ettersom Java-samfunnet har fått J2EE-erfaring. Disse designmønstrene identifiserer potensielle problemer som oppstår når de bruker de forskjellige J2EE-spesifiserte teknologiene og hjelper utviklere med å konstruere kravene til en applikasjonsarkitektur. Det populære Front Controller designmønsteret forvandler for eksempel ustrukturert servletkode til en kontroller som minner om den raffinerte GUI-utviklingen (grafisk brukergrensesnitt).
J2EE designmønstre identifiserer de domeneproblemene som mest sannsynlig vises i J2EE-prosjektene dine. Faktisk, hvis problemene var sjeldne, ville designmønstrene ikke ha utviklet seg for å møte dem. Med det i tankene, vil du ha nytte av å løse hvert domeneproblem i arkitekturen din. For å løse dem alle, opprett en sjekkliste for å validere arkitekturen for fullstendighet. Den prosessen står i kontrast med prosessen for designutviklingsmønstrene for programvare jeg diskuterer neste, da du trenger å bruke disse mønstrene bare når og hvis det er aktuelt.
Så hvor finner du J2EE designmønstre? Sun Microsystems tilbyr to bøker som inneholder mange J2EE-mønstre:
- J2EE BluePrint Groups Designe Enterprise-applikasjoner med Java 2-plattformen (Enterprise Edition), Nicholas Kassem et al. (Addison-Wesley, 2000; ISBN: 0201702770)
- Sun Professional Services Groups Core J2EE Patterns: Best Practices and Design Strategies, Deepak Alur, John Crupi og Dan Malks (Prentice Hall, 2001; ISBN: 0130648841)
(Se Ressurser for lenker til begge bøkene.)
Utover Suns ressurser, tilbyr andre publikasjoner J2EE designmønsterinformasjon, inkludert forskjellige Java-bransjemagasiner eller nettsteder (som f.eks JavaWorld), samt mange bøker. (Se Ressurser for lenker til noen av disse nettstedene, inkludert JavaWorld 's Design mønstre Aktuell indeksside.)
Programvareutviklingsdesignmønstre
Vær også oppmerksom på programvareutviklingsdesignmønstre, delt inn i generelle objektorienterte (OO) designmønstre og Java-spesifikke designmønstre. Fabrikkmønsteret representerer for eksempel et kraftig OO-mønster for innkapsling av gjenstander for å muliggjøre gjenbruk og oppfylle systemets skiftende krav. Java-språk designmønstre står for sin side for Java-spesifikasjoner. Noen er unike for Java og er vanligvis uformelle (for eksempel unntak og primitiver), mens andre er OO-mønstre raffinert for å gjelde Java. Den berømte Gang of Four-boken, Design mønstre av Eric Gamma et al., beskriver mange generelle programvareutviklingsmønstre som er nyttige for alle programmerere.
Ikke avvis disse mønstrene bare fordi de ikke er J2EE-spesifikke. Tvert imot kan slike mønstre vise seg like kraftige, om ikke mer, enn J2EE designmønstre, fordi:
- Mens J2EE-designmønstrene er nye og utvikler seg (fordi J2EE er nye og utvikler seg), har de andre mønstrene nytte av alderen, siden industrien har hatt mer tid til å gjennomgå og foredle dem.
- De tjener ofte som grunnlaget som J2EE-designmønstrene stammer fra.
- De bygger grunnlaget som de J2EE-spesifikke løsningene implementeres på. Å konstruere dette fundamentet riktig påvirker i stor grad hele arkitekturens robusthet og utvidbarhet. Hvis ikke konstruert riktig, vil fundamentet minimere arkitekturens nytte uansett hvor mange J2EE-problemer den løser.
Ikke lag en sjekkliste som dekker programvareutviklingsmønstrene arkitekturen din krever, slik du ville gjort med J2EE-mønstrene. Bruk i stedet slike mønstre der det er hensiktsmessig basert på prosjektets spesifikke utfordringer. Mange utviklere tror feilaktig at produktene deres vil bli bedre hvis de bruker flere mønstre - eller hvis de bruker dem alle! Dette er imidlertid ikke tilfelle. Bruk skjønn og finesse når du bestemmer hvilke mønstre du skal bruke og hvordan du bruker dem sammen.
Designmønstre: Hvor er koden?
Husk at designmønstre ikke kommer med den nøyaktige implementeringen eller kildekoden du vil bruke. Designmønstretilbud spenner fra sparsomme tekstbeskrivelser til rik dokumentasjon til muligens noen eksempler på kode. Utfordringen kommer i å bruke mønstrenes kraftige ideer. Disse ideene må brukes på miljøet de skal brukes i; miljøet definerer riktig implementering.
Som en analogi kan du vurdere et designmønster for å bygge et huss fundament. Designmønsteret identifiserer problemet, konteksten og den mulige løsningen for å bygge fundamentet - informasjon som er enormt verdifull for bygningsarbeideren i felt. Arbeideren må likevel bygge fundamentet. Ville ikke den bygningsarbeideren tjent mer på å få grunnlaget (i likhet med at programvareutvikleren fikk implementeringen)? Kanskje dette fundamentet bare ville være en betongplate som huset kunne bygges på. Problemet: Fundamentet må integreres med selve huset og landet der huset skal bo. Hvordan kan et slikt ferdig bygget fundament romme alle mulige husplaner (rektangel, firkant og andre merkelige former) og alle mulige landskap (på toppen av en høyde, midt i en skog og så videre)?
Tilbake i programvareverdenen er muligheten for å bruke ferdigbygde designmønstre hengslet på to faktorer:
- Implementeringen, ikke individuelle designmønstre, representerer en løsning. Løsningen kan inneholde flere designmønstre, og ved å vite det hvordan de individuelle designmønstrene spiller sammen.
- Løsningen må være tilpasningsdyktig, som svarer på det endelige spørsmålet fra analogien til det ferdigbygde fundamentet: fundamentet må kunne tilpasse seg terrenget og plantegningene. Som du kan forestille deg, vil det ta en ekstremt dyktig håndverker å bygge det tilpasningsdyktige fundamentet i motsetning til standardfundamentet.
Vanlige designmønstre
Tabellen nedenfor viser noen vanlige designmønstre fra både J2EE-kilder og bredere OO-mønstre.
Vanlige designmønstre
|
La oss se på to eksempler på J2EE designmønster: Session Facade og Value Object mønstre. Begge demonstrerer hvordan J2EE-designmønstre fokuserer på problemer som er spesielle for J2EE-miljøet, i motsetning til designmønstrene for programvareutvikling som vanligvis gjelder ethvert programutviklingsarbeid.
Eksempel: Session Facade J2EE mønster
Session Facade mønsteret utviklet seg fra erfaringer med Enterprise JavaBeans (EJBs). Systemer bygget på den nylig introduserte EJB-ene (som kommuniserer med en database) ble tregere til en gjennomgang. Ytelsestesting avdekket problemer som stammer fra flere nettverkssamtaler som ble gjort når de kommuniserte med enhetens EJB, som la til overhead for å etablere nettverkstilkoblingen, seriell data for både sending og mottak, og andre effekter.
Som svar forbedret Session Facade-mønsteret ytelsen ved å sentralisere de flere nettverkshitene i en enkelt samtale. Session Facade benytter en statsløs sesjon EJB for å megle mellom klientsamtalen og den nødvendige enhetens EJB-interaksjon. Flere mønstre eksisterer for å forbedre ytelsen til databasetilgang, inkludert Fast Lane Reader og Data Access Object mønstre.
Eksempel: Verdiobjektet J2EE-mønster
Value Object J2EE-mønsteret har også som mål å forbedre ytelsen til systemer som bruker EJB-er over nettverket. De overhead-induserende nettverkssamtalene fra forrige eksempel henter individuelle datafelt. For eksempel kan du ha en Person enhet EJB med metoder som getFirstName (), getMiddleName (), og getLastName (). Med designmønsteret Value Object kan du redusere slike flere nettverkssamtaler til en enkelt samtale med en metode på enheten EJB, for eksempel getPersonValueObject (), som returnerer dataene samtidig. Det verdiobjektet inneholder dataene som enheten EJB representerer, og som du kan få tilgang til etter behov uten å pådra seg overhead for nettverkssamtalet.
Eksempel: Flyvevekt OO-mønster
For et eksempel på et bredt anvendelig OO-designmønster, bør du vurdere Flyweight-mønsteret, som forbedrer applikasjonsytelsen gjennom gjenbruk av objekter. OO-programvare produserer overhead - bortkastede CPU-sykluser, søppeloppsamling og minnetildeling - når den oppretter og ødelegger objekt. Hvis systemet kunne gjenbruke disse gjenstandene, kan du unngå overhead. Objektene er ofte ikke gjenbrukbare, fordi de inneholder informasjon (kalt stat) spesifikt for objektets nåværende bruker. Flyvektmønsteret gir tilnærminger for å flytte den tilstanden andre steder, slik at resten av objektet kan brukes på nytt.
Sett dem alle sammen: Persistenseksempel
Nå som du kjenner det grunnleggende, kan du begynne å bruke designmønstre i utviklingspraksisen din. Men hvordan bruker du egentlig mønstre? Begynn med å identifisere et domene eller teknisk problem som krever en løsning. Utholdenhet - å løse den eldgamle uoverensstemmelsen mellom objekt og forhold-database - er et godt eksempel for de fleste bedriftsapplikasjoner. La oss se trinnene som kreves for å designe og bygge en applikasjonsarkitekturs persistenslag.
Etter den tradisjonelle OO-arkitekturen og designtilnærmingen, opprett brukstilfeller som beskriver utholdenhetsbehovene dine. Mulige bruksområder inkluderer:
- Objektets utholdenhet bør være gjennomsiktig fra utviklernes synspunkt.
- Persistensmekanismer - enhets-EJBer, datatilgangsobjekter og så videre - skal kunne konfigureres på arkitektonisk nivå.
- Vår arkitektur skal bruke J2EE-teknologier, men innkapsle J2EE-avhengigheter. Vi skal kunne endre leverandører av J2EE-applikasjonsserver, J2EE-versjoner, eller erstatte J2EE helt uten å kreve en hel programrevisjon.
- Det resulterende utholdenhetslaget skal kunne brukes på tvers av prosjekter. Dette bør være en del av vår pågående applikasjonsarkitektur.
Når du har identifisert problemet, kan du bestemme hvilke mønstre som gjelder. Husk at for J2EE-mønstrene, bør du bestemme hvilke mønstre som gjelder i problemområdet og adressere dem. For utholdenhet er de relevante J2EE designmønstrene (se Suns J2EE designmønsterbøker i Resources):
- Verdiobjekt
- Fast Lane Reader
- Data Access Object
- Sesjonsfasade
- Sammensatt enhet
- Verdilistehåndterer
Siden du vil ansette EJB, må du inkludere forretningsdelegat- og tjenestelokatormønstrene for å adressere EJB-tilgang.
I tillegg krever løsning av andre og tredje brukstilfeller tradisjonelle designmønstre for programvareutvikling. Hvordan innkapsler du avhengigheter og har konfigurerbare utholdenhetsmekanismer? Noen gjeldende programvareutviklingsmønstre inkluderer:
- Fabrikk
- Megler
- Strategi
