Designmønstre giver bedre J2EE apps

Siden starten har J2EE (Java 2 Platform, Enterprise Edition) forenklet konstruktion af virksomhedsapplikationer i Java. Efterhånden som J2EE bliver bredere vedtaget, er udviklere imidlertid klar over behovet for definerede tilgange, der både forenkler og standardiserer applikationsopbygning. Du kan begynde at nå dette mål ved at standardisere din ansøgnings arkitektoniske lag.

Det arkitektoniske lag indkapsler generelt en applikations tekniske kompleksiteter uafhængigt af forretningslogikken, hvilket giver en løs kobling mellem forretningsfunktionaliteten og den underliggende tekniske infrastruktur. I denne artikel forklarer jeg en ny metode til opbygning af applikationsarkitekturen til J2EE-projekter - en der anvender designmønstre for at give den standardisering og enkelhed, som god arkitektur kræver.

Applikationsarkitektur og J2EE

J2EE er en fantastisk infrastrukturteknologi. Det giver en ensartet standard for teknologiestakens opgaver på lavere niveau, såsom databasekommunikation eller applikationsdistribution. J2EE fører dog ikke udviklere til at opbygge vellykkede applikationer. J2EEs skabere, der kiggede ned i teknologiestakken, spekulerede på: "Hvordan kan vi standardisere disse API'er?" De skulle have kigget op på applikationsudviklerne og spurgt: "Hvordan kan jeg give udviklere de byggesten, de har brug for for at fokusere på deres forretningsapplikation?"

Når man starter et nyt J2EE-projekt, spørger nogle teammedlemmer ofte: "Hvis J2EE i sig selv er en arkitektur, hvorfor har vi brug for mere?" Mange udviklere mente, at misforståelsen i J2EEs tidlige dage, men erfarne J2EE-udviklere forstår, at J2EE ikke leverer den applikationsarkitektur, der er nødvendig for konsekvent at levere applikationer af høj kvalitet. Disse udviklere bruger ofte designmønstre til at udfylde dette hul.

Design mønstre

Ved programmering giver designmønstre dig mulighed for at udnytte udviklerfællesskabets samlede oplevelse ved at dele problemer og løsninger, der kommer alle til gode. Et designmønster skal fange et problems definition og kontekst, en mulig løsning og løsningens konsekvenser.

Med henblik på J2EE-applikationsarkitektur falder designmønstre i to kategorier: generelle softwareudviklingsmønstre og de mønstre, der identificerer specifikke J2EE-udfordringer. J2EE-specifikke designmønstre identificerer det minimale sæt kendte problemer, som en solid applikationsarkitektur skal løse. Den tidligere gruppe, den af softwareudviklingsmønstre, der ikke er specifikke for J2EE, viser sig lige så stærk - ikke til at identificere problemer, men til at lede arkitekturkonstruktionen.

Lad os undersøge hvert område mere detaljeret.

J2EE design mønstre

J2EE designmønstre har udviklet sig i løbet af de sidste par år, da Java-samfundet har fået J2EE-erfaring. Disse designmønstre identificerer potentielle problemer, der opstår, når de bruger forskellige J2EE-specificerede teknologier og hjælper udviklere med at konstruere en applikationsarkitekturs krav. Det populære Front Controller designmønster omdanner for eksempel ustruktureret servletkode til en controller, der minder om den raffinerede GUI (grafisk brugergrænseflade) udvikling.

J2EE designmønstre identificerer de domæne problemer, der mest sandsynligt vises i dine J2EE projekter. Faktisk, hvis problemerne var sjældne, ville designmønstrene ikke have udviklet sig til at imødekomme dem. Med det i tankerne vil du drage fordel af at løse hvert domæneproblem i din arkitektur. For at løse dem alle skal du oprette en tjekliste for at validere din arkitektur for fuldstændighed. Denne proces står i kontrast til processen for softwareudviklingsdesignmønstre, jeg diskuterer næste gang, da du kun skal anvende disse mønstre, når og hvis det er relevant.

Så hvor finder du J2EE designmønstre? Sun Microsystems tilbyder to bøger, der indeholder mange J2EE-mønstre:

J2EE BluePrint Groups Design af Enterprise-applikationer med Java 2-platformen (Enterprise Edition), Nicholas Kassem et al. (Addison-Wesley, 2000; ISBN: 0201702770)
Sun Professional Services Groups Core J2EE-mønstre: bedste praksis og designstrategier, Deepak Alur, John Crupi og Dan Malks (Prentice Hall, 2001; ISBN: 0130648841)

(Se ressourcer for links til begge bøger.)

Ud over Suns ressourcer tilbyder andre publikationer information om J2EE-designmønstre, herunder forskellige Java-tidsskrifter eller websteder (f.eks JavaWorld) samt adskillige bøger. (Se Ressourcer for links til nogle af disse websteder, herunder JavaWorld 's Designmønstre Aktuel indeksside.)

Designmønstre til softwareudvikling

Vær også opmærksom på softwareudviklingsdesignmønstre, opdelt i generelle objektorienterede (OO) designmønstre og Java-specifikke designmønstre. Fabriksmønsteret repræsenterer for eksempel et kraftigt OO-designmønster til indkapsling af objektoprettelse for at muliggøre genbrug og imødekomme et systems skiftende krav. Java-sprog designmønstre tegner sig for Java-sprogspecifikationer. Nogle er unikke for Java og er normalt uformelle (for eksempel undtagelser og primitiver), mens andre er OO-mønstre raffineret til at gælde for Java. Den berømte Gang of Four-bog, Designmønstre af Eric Gamma et al., beskriver talrige generelle softwareudviklingsmønstre, der er nyttige for alle programmører.

Afvis ikke disse mønstre, simpelthen fordi de ikke er J2EE-specifikke. Tværtimod kan sådanne mønstre vise sig lige så stærke, hvis ikke mere, end J2EE designmønstre, fordi:

Mens J2EE-designmønstrene er nye og udvikler sig (fordi J2EE er nye og udvikler sig), drager de andre mønstre fordel af alderen, da industrien har haft mere tid til at gennemgå og forfine dem.
De tjener ofte som det grundlag, som J2EE-designmønstrene stammer fra.
De bygger det fundament, hvorpå de J2EE-specifikke løsninger implementeres. Opbygning af dette fundament påvirker i vid udstrækning hele arkitekturens robusthed og udvidelighed. Hvis det ikke er konstrueret korrekt, vil fundamentet minimere arkitekturens anvendelighed uanset hvor mange J2EE-problemer det løser.

Lav ikke en tjekliste, der dækker de softwareudviklingsmønstre, som din arkitektur kræver, som du ville gøre med J2EE-mønstre. Brug i stedet sådanne mønstre, hvor det er relevant, baseret på dit projekts specifikke udfordringer. Mange udviklere tror fejlagtigt, at deres produkter vil blive bedre, hvis de bruger flere mønstre - eller hvis de bruger dem alle! Dette er imidlertid ikke tilfældet. Brug diskretion og finesse, når du beslutter dig for, hvilke mønstre du vil anvende, og hvordan du bruger dem sammen.

Designmønstre: Hvor er koden?

Husk, at designmønstre ikke kommer med den nøjagtige implementering eller kildekode, du vil bruge. Designmønstre tilbud spænder fra sparsomme tekstbeskrivelser til rig dokumentation til muligvis en prøvekode. Udfordringen kommer i at anvende mønstrenes stærke ideer. Disse ideer skal anvendes på det miljø, hvor de vil blive brugt; miljøet definerer den korrekte implementering.

Som en analogi, overvej et designmønster til opbygning af et huss fundament. Designmønsteret identificerer problemet, konteksten og den mulige løsning til konstruktion af fundamentet - information, der er meget værdifuld for bygningsarbejderen i marken. Arbejdstageren skal dog stadig bygge fundamentet. Ville den byggearbejder ikke have mere fordel af at få fundamentet (svarende til softwareudvikleren, der fik implementeringen)? Måske ville dette fundament bare være en betonplade, som huset kunne bygges på. Problemet: Fundamentet skal integreres med selve huset og det land, hvor huset skal bo. Hvordan kan et sådant forudbygget fundament rumme alle mulige husbundplaner (rektangel, firkant og andre ulige former) og alle mulige landskaber (på toppen af en bakke, midt i en skov osv.)?

Tilbage i softwareverdenen er muligheden for at bruge forudbyggede designmønstre afhængig af to faktorer:

Implementeringen, ikke individuelle designmønstre, repræsenterer en løsning. Løsningen kunne omfatte flere designmønstre, og ved at vide det, hvordan de individuelle designmønstre spiller sammen.
Løsningen skal være tilpasningsdygtig, hvilket svarer på det sidste spørgsmål fra analogien med det forudbyggede fundament: fundamentet skal være i stand til at tilpasse sig terrænet og grundplanerne. Som du kan forestille dig, ville det tage en ekstremt dygtig håndværker at bygge det tilpasningsdygtige fundament i modsætning til standardfundamentet.

Almindelige designmønstre

Tabellen nedenfor viser nogle almindelige designmønstre fra både J2EE-kilder og bredere OO-mønstre.

Almindelige designmønstre

J2EE design mønstre	Softwareudviklingsmønstre
Sessionsfacade	Singleton
Værdiobjektmontering	Bro
Service Locator Mønster	Prototype
Erhvervsdelegeret	Abstrakt fabrik
Komposit enhed	Flyvægt
Værdilistehåndterer	Mægler
Servicelokator	Strategi
Komposit enhed	Dekoratør
Værdi objekt	Stat
Service til arbejdstager	Iterator
Dataadgangsobjekt	Ansvarlighedskæde
Opfangning af filter	Model View Controller II
Se hjælper	Memento
Sammensat visning	Bygger
Dispatcher-visning	Fabriksmetode

Lad os se på to eksempler på J2EE-designmønstre: Session Facade og Value Object-mønstre. Begge demonstrerer, hvordan J2EE-designmønstre fokuserer på problemer, der er specielle for J2EE-miljøet, i modsætning til softwareudviklingsdesignmønstre, der generelt gælder for enhver applikationsudviklingsindsats.

Eksempel: Session Facade J2EE mønster

Sessionsfacademønsteret udviklede sig fra erfaringer med Enterprise JavaBeans (EJB'er). Systemer bygget på den nyligt introducerede enhed EJB'er (som kommunikerer med en database) blev langsommere til en gennemgang. Ydelsestest afslørede problemer, der stammer fra flere netværksopkald foretaget, når de kommunikerer med enhedens EJB'er, som tilføjede overhead til oprettelse af netværksforbindelsen, serialisering af data til både afsendelse og modtagelse og andre effekter.

Som svar forbedrede Session Facade-mønsteret ydeevnen ved at centralisere disse flere netværkshits i et enkelt opkald. Session Facade anvender en statsløs session EJB til at formidle mellem klientopkaldet og den krævede enhed EJB-interaktion. Der findes flere mønstre til forbedring af databaseadgangsydelse, herunder mønstre for Fast Lane Reader og Data Access Object.

Eksempel: Value Object J2EE mønster

Value Object J2EE-mønsteret har også til formål at forbedre ydeevnen for systemer, der bruger EJB'er over netværket. Disse overheadinducerende netværksopkald fra det foregående eksempel henter individuelle datafelter. For eksempel kan du have en Person enhed EJB med metoder som f.eks getFirstName (), getMiddleName ()og getLastName (). Med designmønsteret Value Object kan du reducere sådanne flere netværksopkald til et enkelt opkald med en metode på enhedens EJB, f.eks. getPersonValueObject (), der returnerer dataene på én gang. Værdiobjektet indeholder de data, som enheden EJB repræsenterer, og som der kan tilgås efter behov uden at pådrage sig netværksopkaldsomkostningerne.

Eksempel: Flyvægt OO-mønster

For et eksempel på et bredt anvendeligt OO-designmønster skal du overveje Flyweight-mønsteret, som forbedrer applikationsydelsen gennem genbrug af objekter. OO-software producerer overhead - spildte CPU-cyklusser, affaldsindsamling og allokering af hukommelse - når det opretter og ødelægger objekt. Hvis systemet kunne genbruge disse genstande, kan du undgå denne omkostning. Objekterne kan ofte ikke genbruges, fordi de indeholder information (kaldet stat) specifikt for objektets aktuelle bruger. Flyvægtsmønsteret giver tilgange til at flytte denne tilstand et andet sted, så resten af objektet kan genbruges.

Sæt dem alle sammen: Persistenseksempel

Nu hvor du kender det grundlæggende, kan du begynde at anvende designmønstre i din udviklingspraksis. Men hvordan bruger du faktisk mønstre? Begynd med at identificere et domæne eller et teknisk problem, der kræver en løsning. Vedholdenhed - løsning af den ældgamle uoverensstemmelse mellem database og relation-database - er et godt eksempel for de fleste virksomhedsapplikationer. Lad os se de nødvendige trin for at designe og opbygge en applikationsarkitekturs persistenslag.

Efter den traditionelle OO-arkitektur og designtilgang skal du oprette brugssager, der beskriver dine persistensbehov. Mulige anvendelsestilfælde inkluderer:

Objektets vedholdenhed skal være gennemsigtig set fra udviklernes synspunkt.
Persistensmekanismer - enheds-EJB'er, dataadgangsobjekter osv. - skal konfigureres på arkitektonisk niveau.
Vores arkitektur skal bruge J2EE-teknologier, men indkapsle J2EE-afhængigheder. Vi skulle være i stand til at ændre leverandører af J2EE-applikationsservere, J2EE-versioner eller erstatte J2EE helt uden at kræve en hel programreparation.
Det resulterende persistenslag skal kunne genbruges på tværs af projekter. Dette skal være en del af vores løbende applikationsarkitektur.

Når du har identificeret problemet, kan du beslutte, hvilke mønstre der skal anvendes. Husk, at for J2EE-mønstre skal du bestemme, hvilke mønstre der gælder i problemområdet, og adressere dem. For vedholdenhed er de relevante J2EE designmønstre (se Suns J2EE designmønsterbøger i ressourcer):

Værdi objekt
Fast Lane Reader
Dataadgangsobjekt
Sessionsfacade
Komposit enhed
Værdilistehåndterer

Da du vil ansætte EJB'er, skal du inkludere Business Delegate og Service Locator-mønstre for at adressere EJB-adgang.

Derudover kræver løsning af anden og tredje brugssag traditionelle designmønstre til softwareudvikling. Hvordan indkapsler du afhængigheder og har konfigurerbare persistensmekanismer? Nogle anvendelige softwareudviklingsmønstre inkluderer: