Nuo pat įkūrimo J2EE („Java 2 Platform“, „Enterprise Edition“) supaprastino įmonės programų kūrimą „Java“. Kai J2EE tampa vis plačiau, kūrėjai supranta, kad reikia apibrėžtų metodų, kurie supaprastintų ir standartizuotų programų kūrimą. Galite pradėti pasiekti šį tikslą standartizuodami savo programas architektūrinis sluoksnis.
Architektūrinis sluoksnis paprastai apima techninius programos sudėtingumus, neatsižvelgiant į verslo logiką, taip užtikrinant laisvą verslo funkcijų ir pagrindinės techninės infrastruktūros sąsają. Šiame straipsnyje paaiškinu besiformuojantį J2EE projektų taikymo architektūros kūrimo metodą, kuris naudoja dizaino modelius, kad užtikrintų standartizavimą ir paprastumą, kurio reikalauja gera architektūra.
Programos architektūra ir J2EE
J2EE yra puiki infrastruktūros technologija. Tai suteikia vienodą technologijos kamino žemesnio lygio užduočių, tokių kaip duomenų bazės ryšys ar programų platinimas, standartą. Tačiau J2EE neveda kūrėjų kurti sėkmingų programų. „J2EE“ kūrėjai, žvelgdami į technologijų šūsnį, stebėjosi: „Kaip mes galime standartizuoti šias API?“ Jie turėjo pasidomėti programų kūrėjais ir paklausti: "Kaip aš galiu suteikti kūrėjams statybinių elementų, reikalingų sutelkti dėmesį į savo verslo taikymą?"
Pradėdami naują J2EE projektą, kai kurie komandos nariai dažnai klausia: "Jei J2EE pati yra architektūra, kodėl mums reikia daugiau?" Daugelis kūrėjų laikėsi tokios klaidingos nuomonės J2EE pradžioje, tačiau patyrę J2EE kūrėjai supranta, kad J2EE nepateikia programų architektūros, reikalingos nuosekliai teikti aukštos kokybės programas. Šie kūrėjai dažnai naudoja dizaino modelius, kad užpildytų šią spragą.
Dizaino modeliai
Programuodami dizaino modeliai leidžia panaudoti kūrėjų bendruomenės bendrą patirtį dalijantis visiems naudingomis problemomis ir sprendimais. Dizaino modelis turi atspindėti problemos apibrėžimą ir kontekstą, galimą sprendimą ir sprendimo pasekmes.
Taikant J2EE programų architektūrą, dizaino modeliai skirstomi į dvi kategorijas: bendruosius programinės įrangos kūrimo modelius ir tuos modelius, kurie identifikuoja konkrečius J2EE iššūkius. J2EE būdingi projektavimo modeliai nustato minimalų žinomų problemų rinkinį, kurį turėtų išspręsti tvirta programų architektūra. Ankstesnė grupė - programinės įrangos kūrimo modelių, nebūdingų J2EE, yra vienodai galinga - ne problemoms nustatyti, o architektūros statybai vadovauti.
Panagrinėkime kiekvieną sritį išsamiau.
J2EE dizaino modeliai
„J2EE“ dizaino modeliai buvo plėtojami per pastaruosius kelerius metus, kai „Java“ bendruomenė įgijo J2EE patirties. Šie dizaino modeliai identifikuoja galimas problemas, su kuriomis susiduriama naudojant įvairias J2EE nurodytas technologijas, ir padeda kūrėjams nustatyti programos architektūros reikalavimus. Pavyzdžiui, populiarus priekinio valdiklio dizaino modelis paverčia nestruktūruotą servleto kodą valdikliu, primenančiu patobulintą GUI (grafinės vartotojo sąsajos) kūrimą.
J2EE dizaino modeliuose nustatomos tos domeno problemos, kurios greičiausiai atsiras jūsų J2EE projektuose. Iš tiesų, jei problemos būtų retos, dizaino modeliai nebūtų išsivystę, kad jas atitiktų. Turint tai omenyje, jums bus naudinga išspręsti kiekvieną domeno problemą savo architektūroje. Norėdami išspręsti juos visus, sukurkite kontrolinį sąrašą, kad patvirtintumėte savo architektūros išsamumą. Šis procesas kontrastuoja su programinės įrangos kūrimo modelių procesu, kurį aptarsiu toliau, nes jums reikia taikyti tuos modelius tik tada, kai tai yra tinkama.
Taigi, kur rasite J2EE dizaino modelius? „Sun Microsystems“ siūlo dvi knygas, kuriose yra daug J2EE modelių:
- „J2EE BluePrint“ grupė Verslo programų kūrimas naudojant „Java 2“ platformą („Enterprise Edition“), Nicholasas Kassemas ir kt. (Addison-Wesley, 2000; ISBN: 0201702770)
- „Sun“ profesionalių paslaugų grupė Pagrindiniai „J2EE“ modeliai: geriausia praktika ir dizaino strategijos, Deepak Alur, John Crupi ir Dan Malks („Prentice Hall“, 2001; ISBN: 0130648841)
(Žr. Šaltinius, kuriuose pateikiamos nuorodos į abi knygas.)
Be „Sun“ šaltinių, kituose leidiniuose pateikiama „J2EE“ dizaino modelio informacija, įskaitant įvairius „Java“ pramonės žurnalus ar svetaines (pvz., „JavaWorld“), taip pat daugybė knygų. (Žr. Šaltinius, kuriuose pateikiamos nuorodos į kai kurias iš šių svetainių, įskaitant „JavaWorld“s Dizaino modeliai Teminės rodyklės puslapis.)
Programinės įrangos kūrimo projektavimo modeliai
Taip pat atkreipkite dėmesį į programinės įrangos kūrimo projektavimo modelius, suskirstytus į bendruosius objektyvius (OO) ir „Java“ specifinius dizaino modelius. Pavyzdžiui, „Factory“ modelis atspindi galingą OO dizaino modelį, skirtą objekto kūrimo talpinimui, kad būtų galima pakartotinai naudoti ir patenkinti besikeičiančius sistemos reikalavimus. Savo ruožtu „Java“ kalbos dizaino modeliai atspindi „Java“ kalbos specifiką. Kai kurie yra unikalūs „Java“ ir dažniausiai yra neformalūs (pavyzdžiui, išimtys ir primityvūs dalykai), o kiti yra OO modeliai, patobulinti pritaikant „Java“. Garsioji „Keturių gauja“ knyga Dizaino modeliai pateikė Ericas Gamma ir kt., pateikia daugybę bendrų programinės įrangos kūrimo modelių, naudingų visiems programuotojams.
Neatmeskite šių modelių vien todėl, kad jie nėra būdingi J2EE. Priešingai, tokie modeliai gali pasirodyti tokie pat galingi, jei ne labiau, nei J2EE dizaino modeliai, nes:
- Nors J2EE dizaino modeliai yra nauji ir besikeičiantys (nes J2EE yra naujas ir besivystantis), kiti modeliai yra naudingi dėl amžiaus, nes pramonė turėjo daugiau laiko juos peržiūrėti ir patobulinti.
- Jie dažnai yra pagrindas, iš kurio kyla J2EE dizaino modeliai.
- Jie kuria pagrindą, ant kurio įgyvendinami J2EE būdingi sprendimai. Teisingai pastačius šį pamatą, tai daro įtaką visos architektūros tvirtumui ir išplėtimui. Jei jis nebus sukonstruotas teisingai, pamatai sumažintų architektūros naudingumą, neatsižvelgiant į tai, kiek J2EE problemų jis išsprendžia.
Nesudarykite kontrolinio sąrašo, apimančio jūsų architektūrai reikalingus programinės įrangos kūrimo modelius, kaip tai darytumėte su J2EE modeliais. Vietoj to, naudokite tokius modelius, jei reikia, atsižvelgiant į konkrečius jūsų projekto iššūkius. Daugelis kūrėjų klaidingai mano, kad jų produktai patobulės, jei jie naudoja daugiau modelių arba jei jie naudoja visus juos! Tačiau taip nėra. Naudokitės diskretiškumu ir švelnumu nuspręsdami, kuriuos modelius naudoti ir kaip juos naudoti kartu.
Dizaino modeliai: kur yra kodas?
Turėkite omenyje, kad dizaino modeliai neatitinka tikslaus įdiegimo ar šaltinio kodo, kurį naudosite. Dizaino modelio pasiūlymai svyruoja nuo retų tekstinių aprašymų iki išsamios dokumentacijos ir galbūt tam tikro kodo pavyzdžio. Iššūkis kyla įgyvendinant galingas modelių idėjas. Šios idėjos turi būti pritaikytos aplinkai, kurioje jos bus naudojamos; aplinka apibrėžia teisingą įgyvendinimą.
Kaip analogiją apsvarstykite namo pamatų statybos modelį. Projektavimo schema identifikuoja problemą, kontekstą ir galimą pagrindo konstrukcijos sprendimą - informacija, nepaprastai vertinga statybos darbininkams šioje srityje. Tačiau darbuotojas vis tiek turi pastatyti pamatą. Ar tam statybų darbuotojui nebus naudingiau, jei jam bus suteiktas pamatas (panašiai kaip programinės įrangos kūrėjui, kuriam suteikta galimybė juos įgyvendinti)? Gal šis pamatas būtų tik betono plokštė, ant kurios būtų galima pastatyti namą. Problema: pamatai turi integruotis su pačiu namu ir žeme, kurioje namas gyvens. Kaip tokiame iš anksto pastatytame pamate galima sutalpinti visus įmanomus namo aukštų planus (stačiakampio, kvadrato ir kitų nelyginių formų) ir visus įmanomus peizažus (kalvos viršūnėje, miško viduryje ir pan.)?
Atgal į programinės įrangos pasaulį, galimybė naudoti iš anksto sukonstruotus dizaino modelius priklauso nuo dviejų veiksnių:
- Įgyvendinimas, o ne individualūs dizaino modeliai, yra sprendimas. Sprendimas galėtų apimti kelis dizaino modelius ir tai darydamas žinotų, kaip atskiri dizaino modeliai veikia kartu.
- Sprendimas turi būti pritaikomas, kuris atsako į galutinį iš anksto pastatyto pamato analogijos klausimą: pamatas turi sugebėti prisitaikyti prie reljefo ir grindų planų. Kaip jūs galite įsivaizduoti, norint pastatyti prisitaikantį pagrindą, priešingai nei standartiniame pamate, prireiks itin kvalifikuoto amatininko.
Bendri dizaino modeliai
Žemiau esančioje lentelėje pateikiami keli įprasti dizaino modeliai iš J2EE šaltinių ir platesnių OO modelių.
Bendri dizaino modeliai
|
Pažvelkime į du J2EE dizaino modelių pavyzdžius: „Session Facade“ ir „Value Object“ modelius. Abi demonstruoja, kaip J2EE projektavimo modeliai sutelkia dėmesį į J2EE aplinkos problemas, o ne į programinės įrangos kūrimo modelius, kurie paprastai taikomi bet kokioms programų kūrimo pastangoms.
Pavyzdys: „Session Facade J2EE“ modelis
„Session Facade“ modelis išsivystė iš patirties su „Enterprise JavaBeans“ (EJB). Sistemos, sukurtos ant naujai pristatytų subjektų EJB (kurie bendrauja su duomenų baze), lėtai nuslinko. Našumo testavimas atskleidė problemas, kylančias dėl kelių tinklo skambučių, atliekamų bendraujant su subjekto EJB, o tai pridėjo pridėtines išlaidas tinklo ryšiui užmegzti, duomenims nuoseklinti tiek siunčiant, tiek priimant ir kitus efektus.
Reaguodamas į tai, „Session Facade“ modelis pagerino našumą, sutelkdamas tuos kelis tinklo įvykius į vieną skambutį. „Sesijos fasadas“ naudoja sesiją be pilietybės EJB, kad tarpininkautų tarp kliento skambučio ir reikalingo subjekto EJB sąveikos. Norint pagerinti prieigą prie duomenų bazės, yra daugiau modelių, įskaitant „Fast Lane Reader“ ir „Data Access Object“ modelius.
Pavyzdys: Value Object J2EE šablonas
„Value Object J2EE“ modeliu taip pat siekiama pagerinti sistemų, kurios tinkle naudoja EJB, našumą. Tie, kurie skatina tinklo skambučius iš ankstesnio pavyzdžio, nuskaito atskirus duomenų laukus. Pavyzdžiui, galite turėti Asmuo subjektas EJB, taikydamas tokius metodus kaip getFirstName (), getMiddleName ()ir getLastName (). Naudodami vertės objekto dizaino modelį, galite sumažinti tokius kelis tinklo skambučius iki vieno skambučio, naudodami objektą EJB, pvz., getPersonValueObject (), kuris pateikia duomenis iš karto. Tame vertės objekte yra duomenys, kuriuos subjektas atstovauja EJB, ir juos galima pasiekti prireikus nepatiriant tinklo skambučio pridėtinių išlaidų.
Pavyzdys: „Flyweight OO“ modelis
Kaip plačiai taikomo OO dizaino modelio pavyzdį, apsvarstykite „Flyweight“ modelį, kuris pagerina programos našumą pakartotinai naudojant objektą. OO programinė įranga sukuria ir sunaikina objektą pridėtines išlaidas - iššvaistytus procesoriaus ciklus, šiukšlių surinkimą ir atminties paskirstymą. Jei sistema galėtų pakartotinai naudoti tuos objektus, galite išvengti šios pridėtinės sumos. Tačiau objektai dažnai nėra pakartotinai naudojami, nes juose yra informacijos (vadinamos valstija) būdingas dabartiniam objekto vartotojui. „Flyweight“ modelis pateikia būdus, kaip tą būseną perkelti kitur, kad likusią objektą būtų galima pakartotinai naudoti.
Sudėkite juos visus kartu: atkaklumo pavyzdys
Dabar, kai žinote pagrindus, galite pradėti taikyti dizaino modelius savo kūrimo praktikoje. Bet kaip jūs iš tikrųjų naudojate modelius? Pirmiausia nustatykite domeną ar techninę problemą, kurią reikia išspręsti. Nuolatumas - išspręsti senų objektų ir santykių duomenų bazių neatitikimus - yra geras pavyzdys daugumai įmonės programų. Pažiūrėkime veiksmus, kurių reikia norint sukurti ir sukurti programos architektūros patvarumo sluoksnį.
Laikydamiesi tradicinio OO architektūros ir dizaino požiūrio, sukurkite naudojimo atvejus, apibūdinančius jūsų atkaklumo poreikius. Galimi naudojimo atvejai:
- Kūrėjų požiūriu objektų atkaklumas turėtų būti skaidrus.
- Patvarumo mechanizmai - subjekto EJB, duomenų prieigos objektai ir pan. - turėtų būti konfigūruojami architektūros lygiu.
- Mūsų architektūra turėtų naudoti J2EE technologijas, tačiau apimti J2EE priklausomybes. Turėtume turėti galimybę pakeisti „J2EE“ programų serverių tiekėjus, „J2EE“ versijas arba visiškai pakeisti „J2EE“ nereikalaudami visos programos pertvarkymo.
- Gautas patvarumo sluoksnis turėtų būti pakartotinai naudojamas visuose projektuose. Tai turėtų būti mūsų vykdomos programos architektūros dalis.
Nustačius problemą, galite nuspręsti, kurie modeliai taikomi. Atminkite, kad J2EE modeliams turėtumėte nustatyti, kurie modeliai taikomi probleminėje srityje, ir juos spręsti. Išliekamumui svarbūs J2EE dizaino modeliai yra (žr. „Sun“ J2EE dizaino modelių knygas ištekliuose):
- Vertės objektas
- „Fast Lane Reader“
- Duomenų prieigos objektas
- Seanso fasadas
- Sudėtinis subjektas
- Vertybių sąrašo tvarkytuvas
Kadangi naudosite EJB, įtraukite „Verslo įgaliotinis“ ir „Paslaugų lokatorius“ modelius, kad išspręstumėte EJB prieigą.
Be to, norint išspręsti antrojo ir trečiojo naudojimo atvejus reikalingi tradiciniai programinės įrangos kūrimo projektavimo modeliai. Kaip sukapsulinti priklausomybes ir turėti konfigūruojamus patvarumo mechanizmus? Kai kurie taikomi programinės įrangos kūrimo modeliai yra šie:
- Gamykla
- Tarpininkas
- Strategija
