Suunnittelumallit parantavat J2EE-sovelluksia

Perustamisestaan ​​lähtien J2EE (Java 2 Platform, Enterprise Edition) on yksinkertaistanut yrityssovellusten rakentamista Javassa. Kun J2EE otetaan käyttöön laajemmin, kehittäjät ymmärtävät kuitenkin tarpeen määriteltyihin lähestymistapoihin, jotka yksinkertaistavat ja standardoivat sovellusten rakentamista. Voit aloittaa tavoitteen saavuttamisen standardoimalla sovelluksesi arkkitehtoninen kerros.

Arkkitehtoninen kerros kiteyttää yleensä sovelluksen teknisen monimutkaisuuden liiketoimintalogiikasta riippumatta ja tarjoaa siten löysän kytkennän liiketoiminnan toimivuuden ja taustalla olevan teknisen infrastruktuurin välille. Tässä artikkelissa selitän uuden menetelmän J2EE-projektien sovellusarkkitehtuurin rakentamiseksi - joka käyttää suunnittelumalleja hyvän arkkitehtuurin edellyttämän standardoinnin ja yksinkertaisuuden tarjoamiseksi.

Sovellusarkkitehtuuri ja J2EE

J2EE on loistava infrastruktuuritekniikka. Se tarjoaa yhtenäisen standardin teknologian pinon alemman tason tehtäville, kuten tietokantaviestinnälle tai sovellusten jakelulle. J2EE ei kuitenkaan saa kehittäjiä rakentamaan onnistuneita sovelluksia. J2EE: n kehittäjät katsoivat alaspäin teknologiapinoa miettien: "Kuinka voimme standardoida nämä sovellusliittymät?" Heidän olisi pitänyt etsiä sovelluskehittäjiä ja kysyä: "Kuinka voin antaa kehittäjille rakennuspalikat, jotka heidän on keskitettävä liiketoimintasovelluksiinsa?"

Aloittaessaan uuden J2EE-projektin jotkut tiimin jäsenet kysyvät usein: "Jos J2EE on itse arkkitehtuuri, miksi me tarvitsemme enemmän?" Monet kehittäjät pitivät tätä väärinkäsitystä J2EE: n alkuaikoina, mutta kokeneet J2EE-kehittäjät ymmärtävät, että J2EE ei tarjoa sovellusarkkitehtuuria, joka tarvitaan korkealaatuisten sovellusten johdonmukaiseen toimittamiseen. Nämä kehittäjät käyttävät usein suunnittelumalleja tuon aukon täyttämiseen.

Suunnittelumalleja

Ohjelmoinnissa suunnittelumallien avulla voit hyödyntää kehittäjäyhteisön kollektiivista kokemusta jakamalla kaikille hyödyllisiä ongelmia ja ratkaisuja. Suunnittelumallissa on otettava huomioon ongelman määritelmä ja asiayhteys, mahdollinen ratkaisu ja ratkaisun seuraukset.

J2EE-sovellusarkkitehtuurin kannalta suunnittelumallit jaetaan kahteen luokkaan: yleiset ohjelmistokehitysmallit ja ne mallit, jotka tunnistavat tietyt J2EE-haasteet. J2EE-spesifiset suunnittelumallit tunnistavat vähiten tunnettuja ongelmia, jotka vankan sovellusarkkitehtuurin pitäisi ratkaista. Entinen ryhmä, ei-J2EE: lle ominaisen ohjelmistokehityksen malli, osoittautuu yhtä tehokkaaksi - ei ongelmien tunnistamiseksi vaan arkkitehtuurin rakentamisen ohjaamiseksi.

Tarkastellaan kutakin aluetta tarkemmin.

J2EE-suunnittelukuviot

J2EE-suunnittelumallit ovat kehittyneet viime vuosina, kun Java-yhteisö on saanut J2EE-kokemuksen. Nämä suunnittelumallit tunnistavat mahdolliset ongelmat, joita esiintyy käytettäessä erilaisia ​​J2EE-määriteltyjä tekniikoita, ja auttavat kehittäjiä laatimaan sovellusarkkitehtuurin vaatimukset. Esimerkiksi suosittu etuohjaimen suunnittelumalli muuntaa rakentamattoman servlet-koodin ohjaimeksi, joka muistuttaa hienostunutta GUI (graafinen käyttöliittymä) -kehitystä.

J2EE-suunnittelumallit tunnistavat ne toimialueongelmat, jotka todennäköisimmin esiintyvät J2EE-projekteissasi. Jos ongelmat olisivat harvinaisia, suunnittelumallit eivät olisi kehittyneet vastaamaan niihin. Tässä mielessä hyödyt siitä, että käsittelemme jokaisen arkkitehtuurin verkkotunnusongelman. Voit ratkaista ne kaikki luomalla tarkistuslistan vahvistaaksesi arkkitehtuurisi täydellisyyden. Tämä prosessi on ristiriidassa ohjelmistokehityksen suunnittelumallien kanssa, josta keskustelen seuraavaksi, koska sinun on sovellettava näitä malleja vain tarvittaessa ja tarvittaessa.

Joten mistä löydät J2EE-suunnittelumallit? Sun Microsystems tarjoaa kaksi kirjaa, jotka sisältävät monia J2EE-kuvioita:

• J2EE BluePrint -ryhmän Suunnittele yrityssovelluksia Java 2 -alustalla (Enterprise Edition), Nicholas Kassem et ai. (Addison-Wesley, 2000; ISBN: 0201702770)
• Sun Professional Services -konserni J2EE-keskeiset mallit: parhaat käytännöt ja suunnittelustrategiat, Deepak Alur, John Crupi ja Dan Malks (Prentice Hall, 2001; ISBN: 0130648841)

(Katso linkit molempiin kirjoihin Resursseista.)

Sunin resurssien lisäksi muut julkaisut tarjoavat J2EE-muotoilutietoja, mukaan lukien erilaiset Java-alan aikakauslehdet tai verkkosivustot (kuten JavaWorld) sekä lukuisia kirjoja. (Katso resursseista linkkejä joihinkin näistä sivustoista, mukaan lukien JavaWorld 's Suunnittelumalleja Ajankohtainen hakemisto.)

Ohjelmistokehityksen suunnittelumallit

Ole myös tietoinen ohjelmistokehityksen suunnittelumalleista, jaettuna yleisiin olioihin (OO) ja Java-spesifisiin suunnittelumalleihin. Esimerkiksi Factory-malli edustaa tehokasta OO-suunnittelumallia objektien luomisen kapseloimiseksi uudelleenkäytön mahdollistamiseksi ja järjestelmän muuttuvien vaatimusten täyttämiseksi. Java-kielen suunnittelumallit puolestaan ​​ottavat huomioon Java-kielen yksityiskohdat. Jotkut ovat ainutlaatuisia Javalle ja ovat yleensä epävirallisia (esimerkiksi poikkeuksia ja alkukantaisia), kun taas toiset ovat OO-malleja, jotka on hienostunut soveltamaan Java-sovelluksiin. Kuuluisa Neljän jengin kirja, Suunnittelumalleja kirjoittanut Eric Gamma et ai., esittelee lukuisia yleisiä ohjelmistokehitysmalleja, jotka ovat hyödyllisiä kaikille ohjelmoijille.

Älä hylkää näitä malleja yksinkertaisesti siksi, että ne eivät ole J2EE-spesifisiä. Päinvastoin, tällaiset mallit voivat osoittautua yhtä voimakkaiksi, ellei enempää, kuin J2EE-suunnittelumallit, koska:

• Vaikka J2EE: n suunnittelumallit ovat uusia ja kehittyviä (koska J2EE on uusi ja kehittyvä), muut mallit hyötyvät iästä, koska teollisuudella on ollut enemmän aikaa tarkistaa ja tarkentaa niitä.
• Ne ovat usein perustana J2EE-suunnittelukuvioiden taustalle.
• Ne rakentavat perustan, jolle J2EE-spesifiset ratkaisut toteutetaan. Tämän perustuksen oikea rakentaminen vaikuttaa laajasti koko arkkitehtuurin kestävyyteen ja laajennettavuuteen. Jos sitä ei rakenneta oikein, säätiö minimoisi arkkitehtuurin hyödyllisyyden riippumatta siitä, kuinka monta J2EE-ongelmaa se ratkaisee.

Älä tee tarkistusluetteloa, joka kattaa arkkitehtuurisi edellyttämät ohjelmistokehitysmallit, kuten tekisit J2EE-mallien kanssa. Käytä sen sijaan tällaisia ​​malleja tarvittaessa projektisi erityisten haasteiden perusteella. Monet kehittäjät uskovat virheellisesti, että heidän tuotteitaan parannetaan, jos he käyttävät enemmän malleja - tai jos he käyttävät kaikkia niitä! Näin ei kuitenkaan ole. Käytä harkintaa ja hienovaraisuutta päättäessäsi mitä malleja käytetään ja miten niitä käytetään yhdessä.

Suunnittelumallit: Missä koodi on?

Muista, että suunnittelumallien mukana ei tule tarkkaa toteutusta tai lähdekoodia. Suunnittelumallitarjonta vaihtelee harvoista tekstikuvista runsaaseen dokumentaatioon mahdollisesti mallikoodiin. Haasteena on kuvioiden voimakkaiden ideoiden soveltaminen. Näitä ideoita on sovellettava ympäristöön, jossa niitä käytetään; ympäristö määrittelee oikean toteutuksen.

Harkitse analogisesti talon perustuksen rakennemallia. Suunnittelumalli identifioi ongelman, kontekstin ja mahdollisen ratkaisun perustuksen rakentamiseen - tiedot, jotka ovat erittäin arvokkaita kentän rakennusalan työntekijöille. Työntekijän on kuitenkin edelleen rakennettava perusta. Eikö rakennusalan työntekijä hyötyisi enemmän siitä, että hänelle annettaisiin perusta (samanlainen kuin ohjelmistokehittäjälle, jolle toteutus annetaan)? Ehkä tämä säätiö olisi vain betonilaatta, jolle talo voitaisiin rakentaa. Ongelma: Säätiön on integroitava itse talon ja maan kanssa, jossa talo asuu. Kuinka tällaiseen valmiiksi rakennettuun pohjaan mahtuu kaikki mahdolliset talon pohjapiirrokset (suorakulmio, neliö ja muut parittomat muodot) ja kaikki mahdolliset maisemat (kukkulan päällä, keskellä metsää ja niin edelleen)?

Ohjelmistomaailmassa valmiiden suunnittelumallien käyttökelpoisuus riippuu kahdesta tekijästä:

• Toteutus, ei yksittäiset suunnittelumallit, edustaa ratkaisua. Ratkaisu voisi sisältää useita suunnittelumalleja ja tietäen samalla, kuinka yksittäiset suunnittelumallit toimivat yhdessä.
• Ratkaisun on oltava mukautuva, mikä vastaa viimeiseen kysymykseen esivalmistetun perustuksen analogiasta: perustuksen on kyettävä sopeutumaan maastoon ja pohjapiirustuksiin. Kuten voitte kuvitella, sopeutuvan perustuksen rakentaminen tavanomaisen perustan sijaan vaatii erittäin ammattitaitoisen käsityöläisen.

Yleiset suunnittelumallit

Alla olevassa taulukossa luetellaan joitain yleisiä suunnittelumalleja sekä J2EE-lähteistä että laajemmista OO-malleista.

Tarkastellaan kahta esimerkkiä J2EE-mallikuvioista: istunnon julkisivu- ja arvoobjektikuviot. Molemmat osoittavat, kuinka J2EE-suunnittelumallit keskittyvät erityisesti J2EE-ympäristössä esiintyviin ongelmiin, toisin kuin ohjelmistokehityksen suunnittelumallit, joita yleensä sovelletaan sovellusten kehittämiseen.

Esimerkki: Istunnon julkisivun J2EE-kuvio

Istunnon julkisivumalli on kehittynyt kokemuksista Enterprise JavaBeans (EJB) -sovelluksista. Äskettäin esiteltyihin EJB-yksiköihin (jotka kommunikoivat tietokannan kanssa) rakennetut järjestelmät olivat hidastumassa indeksointiin. Suorituskykytestaus paljasti ongelmat, jotka johtuvat useista verkkopuheluista, joita soitettiin ollessaan yhteydessä EJB-yksiköiden kanssa, mikä lisäsi yleiskustannuksia verkkoyhteyden muodostamiseen, tietojen sarjallisuuteen sekä lähettämistä että vastaanottamista varten sekä muita vaikutuksia.

Vastauksena Session Facade -kuvio paransi suorituskykyä keskittämällä nämä useat verkko-osumat yhteen puheluun. Istunnon julkisivu käyttää valtiotonta istunto EJB: tä välittämään asiakaspuhelun ja vaaditun entiteetin EJB-vuorovaikutuksen. Tietokannan käytön suorituskyvyn parantamiseksi on enemmän malleja, mukaan lukien Fast Lane Reader- ja Data Access Object -mallit.

Esimerkki: Value Object J2EE -malli

Value Object J2EE -kuvion tarkoituksena on myös parantaa EJB: itä verkon kautta käyttävien järjestelmien suorituskykyä. Edellisen esimerkin mukaiset yleiskustannukset aiheuttavat verkkopuhelut hakevat yksittäisiä tietokenttiä. Sinulla voi olla esimerkiksi Henkilö yhteisö EJB menetelmillä, kuten getFirstName (), getMiddleName ()ja getLastName (). Arvoobjektin suunnittelumallin avulla voit vähentää tällaiset useita verkkopuheluja yhdeksi puheluksi entiteetin EJB: n menetelmällä, kuten getPersonValueObject (), joka palauttaa tiedot kerralla. Tämä arvo-objekti sisältää tiedot, joita entiteetti EJB edustaa, ja niihin pääsee tarvittaessa tarvittaessa aiheuttamatta verkkopuhelun yleiskustannuksia.

Esimerkki: Flyweight OO -malli

Harkitse esimerkkiä laajasti sovellettavasta OO-suunnittelumallista Flyweight-kuvio, joka parantaa sovelluksen suorituskykyä objektin uudelleenkäytön avulla. OO-ohjelmisto tuottaa ylimääräisiä - hukkaan menneitä suorittimen jaksoja, roskien keräystä ja muistin allokointia -, kun se luo ja tuhoaa objektin. Jos järjestelmä voisi käyttää näitä objekteja uudelleen, voit välttää tämän yleiskustannukset. Kohteita ei kuitenkaan voida käyttää uudelleen, koska ne sisältävät tietoa (kutsutaan osavaltio), joka on ominaista objektin nykyiselle käyttäjälle. Flyweight-kuvio tarjoaa lähestymistapoja kyseisen tilan siirtämiseen muualle, jotta loput kohteesta voidaan käyttää uudelleen.

Laita ne kaikki yhteen: Esimerkki sinnikkyydestä

Nyt kun tiedät perusasiat, voit aloittaa suunnittelumallien soveltamisen kehityskäytäntöihisi. Mutta miten todella käytät malleja? Aloita tunnistamalla toimialue tai tekninen ongelma, joka vaatii ratkaisun. Pysyvyys - ikivanhan objekti-relaatiotietokanta-ristiriidan ratkaiseminen - on hyvä esimerkki useimmille yrityssovelluksille. Katsotaanpa vaiheet, jotka tarvitaan sovellusarkkitehtuurin pysyvyyskerroksen suunnitteluun ja rakentamiseen.

Perinteisen OO-arkkitehtuurin ja suunnittelun mukaisesti luo käyttötapauksia, jotka kuvaavat pysyvyystarpeitasi. Mahdollisia käyttötapauksia ovat:

1. Objektin pysyvyyden tulee olla kehittäjien näkökulmasta läpinäkyvä.
2. Pysyvyysmekanismien - kokonaisuuden EJB: n, tiedonsiirtoobjektien ja niin edelleen - pitäisi olla konfiguroitavissa arkkitehtonisella tasolla.
3. Arkkitehtuurissamme tulisi käyttää J2EE-tekniikoita, mutta kapseloida J2EE-riippuvuudet. Meidän pitäisi pystyä vaihtamaan J2EE-sovelluspalvelimen toimittajia, J2EE-versioita tai korvaamaan J2EE kokonaan ilman, että tarvitsemme koko sovelluksen uudistusta.
4. Tuloksena olevan pysyvyyskerroksen tulisi olla uudelleenkäytettävissä kaikissa projekteissa. Tämän pitäisi olla osa jatkuvaa sovellusarkkitehtuuriamme.

Kun olet tunnistanut ongelman, voit päättää sovellettavista malleista. Muista, että J2EE-kuvioiden osalta sinun on määritettävä ongelmakohdassa käytettävät mallit ja puututtava niihin. Pysyvyyden kannalta merkitykselliset J2EE-suunnittelumallit ovat (katso Sunin J2EE-mallikirjat Resursseista):

• Arvo-objekti
• Nopea kaistalukija
• Tietojen käyttöobjekti
• Istunnon julkisivu
• Yhdistetty kokonaisuus
• Arvolistan käsittelijä

Koska käytät EJB: itä, sisällytä Business Delegate- ja Service Locator -mallit EJB-pääsyn käsittelemiseksi.

Lisäksi toisen ja kolmannen käyttötapauksen ratkaiseminen edellyttää perinteisiä ohjelmistokehityksen suunnittelumalleja. Kuinka kapseloit riippuvuudet ja sinulla on konfiguroitavat pysyvyysmekanismit? Joitakin sovellettavia ohjelmistokehitysmalleja ovat:

• Tehdas
• Välittäjä
• Strategia