Kopš savas darbības sākuma J2EE (Java 2 Platform, Enterprise Edition) ir vienkāršojis uzņēmuma lietojumprogrammu izveidi Java. Kad J2EE kļūst arvien plašāk pieņemts, izstrādātāji saprot, ka ir vajadzīgas noteiktas pieejas, kas gan vienkāršo, gan standartizē lietojumprogrammu veidošanu. Jūs varat sākt sasniegt šo mērķi, standartizējot lietojumprogrammas arhitektūras slānis.
Arhitektūras slānis parasti ietver lietojumprogrammas tehnisko sarežģītību neatkarīgi no biznesa loģikas, tādējādi nodrošinot brīvu saikni starp biznesa funkcionalitāti un pamatā esošo tehnisko infrastruktūru. Šajā rakstā es izskaidroju jauno metodi lietojumprogrammu arhitektūras veidošanai J2EE projektiem - tādu, kurā tiek izmantoti dizaina modeļi, lai nodrošinātu standartizāciju un vienkāršību, kas nepieciešama labai arhitektūrai.
Lietojumprogrammu arhitektūra un J2EE
J2EE ir lieliska infrastruktūras tehnoloģija. Tas nodrošina vienotu standartu tehnoloģiju kaudzes zemākā līmeņa uzdevumiem, piemēram, datu bāzes saziņai vai lietojumprogrammu izplatīšanai. J2EE tomēr neliecina izstrādātājus veidot veiksmīgas lietojumprogrammas. J2EE veidotāji, skatoties uz leju tehnoloģiju kaudzē, brīnījās: "Kā mēs varam standartizēt šīs API?" Viņiem vajadzēja uzmeklēt lietojumprogrammu izstrādātājus un jautāt: "Kā es varu izstrādātājiem dot pamatelementus, kas viņiem jākoncentrējas uz viņu biznesa lietojumprogrammām?"
Uzsākot jaunu J2EE projektu, daži komandas locekļi bieži jautā: "Ja J2EE pati ir arhitektūra, kāpēc mums vajag vairāk?" Daudzi izstrādātāji uzskatīja, ka J2EE agrīnā dienās bija nepareizs uzskats, bet pieredzējuši J2EE izstrādātāji saprot, ka J2EE nespēj nodrošināt lietojumprogrammu arhitektūru, kas nepieciešama, lai konsekventi piegādātu augstas kvalitātes lietojumprogrammas. Šie izstrādātāji bieži izmanto dizaina modeļus, lai aizpildītu šo plaisu.
Dizaina modeļi
Programmējot, dizaina modeļi ļauj jums izmantot izstrādātāju kopienas kolektīvo pieredzi, daloties problēmās un risinājumos, kas nāk par labu visiem. Dizaina modelim jāaptver problēmas definīcija un konteksts, iespējamais risinājums un risinājuma sekas.
J2EE lietojumprogrammu arhitektūras vajadzībām dizaina modeļi iedalās divās kategorijās: vispārējie programmatūras izstrādes modeļi un modeļi, kas identificē īpašas J2EE problēmas. J2EE raksturīgie dizaina modeļi identificē minimālo zināmo problēmu kopumu, kas būtu jāatrisina stabilai lietojumprogrammu arhitektūrai. Iepriekšējā grupa - programmatūras izstrādes modeļi, kas nav specifiski J2EE, izrādās vienlīdz spēcīgi - nevis problēmu identificēšanai, bet arhitektūras būvniecības vadīšanai.
Apskatīsim katru jomu sīkāk.
J2EE dizaina modeļi
J2EE dizaina modeļi pēdējos gados ir attīstījušies, jo Java kopiena ir ieguvusi J2EE pieredzi. Šie dizaina modeļi identificē iespējamās problēmas, kas radušās, izmantojot dažādas J2EE norādītās tehnoloģijas, un palīdz izstrādātājiem izveidot lietojumprogrammas arhitektūras prasības. Piemēram, populārais priekšējā kontrollera dizaina modelis pārveido nestrukturētu servleta kodu kontrolierī, kas atgādina izsmalcinātu GUI (grafiskā lietotāja saskarne) izstrādi.
J2EE dizaina modeļi identificē tās domēna problēmas, kuras, visticamāk, parādīsies jūsu J2EE projektos. Patiešām, ja problēmas rastos reti, dizaina modeļi nebūtu attīstījušies, lai tās apmierinātu. Paturot to prātā, jums būs noderīgi risināt katru domēna problēmu savā arhitektūrā. Lai tos visus atrisinātu, izveidojiet kontrolsarakstu, lai apstiprinātu savas arhitektūras pilnīgumu. Šis process ir pretrunā ar programmatūras izstrādes dizaina modeļu procesu, kuru es apspriedīšu tālāk, jo šie modeļi jums jāpielieto tikai tad, kad un ja nepieciešams.
Tātad, kur jūs atradīsit J2EE dizaina modeļus? Sun Microsystems piedāvā divas grāmatas, kurās ir daudz J2EE modeļu:
- J2EE BluePrint grupa Uzņēmumu lietojumprogrammu projektēšana, izmantojot Java 2 platformu (Enterprise Edition), Nikolass Kasems un citi. (Addison-Wesley, 2000; ISBN: 0201702770)
- Sun profesionālo pakalpojumu grupa Galvenie J2EE modeļi: paraugprakse un dizaina stratēģijas, Deepaks Alurs, Džons Krupi un Dens Malks (Prentice Hall, 2001; ISBN: 0130648841)
(Saites uz abām grāmatām skatiet resursos.)
Papildus Sun resursiem citās publikācijās tiek piedāvāta informācija par J2EE dizaina modeli, tostarp dažādos Java nozares žurnālos vai vietnēs (piemēram, JavaWorld), kā arī daudzas grāmatas. (Skatīt saites uz dažām no šīm vietnēm, tostarp vietni Resursi JavaWorld 's Dizaina modeļi Aktuālās rādītāja lapa.)
Programmatūras izstrādes dizaina modeļi
Jāapzinās arī programmatūras izstrādes dizaina modeļi, sadalot tos uz vispārējiem objektorientētiem (OO) un Java specifiskiem dizaina modeļiem. Piemēram, rūpnīcas modelis ir spēcīgs OO dizaina modelis objektu izveides iekapsulēšanai, lai nodrošinātu atkārtotu izmantošanu un atbilstu sistēmas mainīgajām prasībām. Savukārt Java valodas dizaina modeļi veido Java valodas specifiku. Daži no tiem ir unikāli Java un parasti ir neformāli (piemēram, izņēmumi un primitīvi), bet citi ir OO modeļi, kas tiek pilnveidoti, lai tos piemērotu Java. Slavenā četru bandu grāmata, Dizaina modeļi Eric Gamma et al., sīki izklāsta daudzus vispārīgus programmatūras izstrādes modeļus, kas noder visiem programmētājiem.
Neatstājiet šos modeļus tikai tāpēc, ka tie nav specifiski J2EE. Tieši pretēji, šādi modeļi var izrādīties tikpat spēcīgi, ja ne vairāk, nekā J2EE dizaina modeļi, jo:
- Kaut arī J2EE dizaina modeļi ir jauni un attīstās (jo J2EE ir jauns un attīstās), pārējie modeļi gūst labumu no vecuma, jo nozarei ir bijis vairāk laika tos pārskatīt un uzlabot.
- Tie bieži kalpo par pamatu, no kura izriet J2EE dizaina modeļi.
- Viņi veido pamatu, uz kura tiek īstenoti J2EE raksturīgie risinājumi. Pareizi uzbūvējot šo pamatu, tiek ietekmēta visas arhitektūras izturība un paplašināmība. Ja tas nav pareizi uzbūvēts, pamats samazinātu arhitektūras lietderību neatkarīgi no tā, cik daudz J2EE problēmu tas atrisina.
Neveidojiet kontrolsarakstu, kas aptver jūsu arhitektūras pieprasītos programmatūras izstrādes modeļus, kā jūs to darītu ar J2EE modeļiem. Tā vietā vajadzības gadījumā izmantojiet šādus modeļus, pamatojoties uz jūsu projekta īpašajām problēmām. Daudzi izstrādātāji kļūdaini uzskata, ka viņu produkti uzlabosies, ja viņi izmantos vairāk modeļu - vai arī, ja viņi izmantos visus! Tomēr tas tā nav. Izmantojiet diskrētumu un izsmalcinātību, izlemjot, kurus modeļus izmantot un kā tos izmantot kopā.
Dizaina modeļi: Kur ir kods?
Paturiet prātā, ka dizaina modeļi nenodrošina precīzu ieviešanu vai jūsu izmantoto avota kodu. Dizaina modeļu piedāvājumi svārstās no retiem tekstuālajiem aprakstiem līdz bagātīgai dokumentācijai līdz, iespējams, koda paraugam. Izaicinājums rodas, izmantojot modeļu spēcīgās idejas. Šīs idejas jāpielieto vidē, kurā tās tiks izmantotas; vide nosaka pareizu ieviešanu.
Kā analoģiju apsveriet nama pamatnes celtniecības dizaina modeli. Projektēšanas modelis identificē problēmu, kontekstu un iespējamo risinājumu pamatu būvniecībai - informācija, kas ir ārkārtīgi vērtīga būvstrādniekam šajā jomā. Strādniekam tomēr ir jāveido pamats. Vai šim būvstrādniekam nebūtu vairāk labuma no tā, ka viņam tiktu piešķirts pamats (līdzīgi kā programmatūras izstrādātājam, kuram tiek piešķirta ieviešana)? Varbūt šis pamats būtu tikai betona plāksne, uz kuras varētu būvēt māju. Problēma: pamatam ir jāintegrējas ar pašu māju un zemi, kurā māja atradīsies. Kā šāds iepriekš uzbūvēts pamats var uzņemt visus iespējamos mājas stāvu plānojumus (taisnstūra, kvadrāta un citas nepāra formas) un visas iespējamās ainavas (kalna galā, meža vidū utt.)?
Programmatūras pasaulē iepriekš izveidotu dizaina modeļu izmantošanas iespējamība ir atkarīga no diviem faktoriem:
- Īstenošana, nevis individuāli dizaina modeļi, ir risinājums. Risinājums varētu ietvert vairākus dizaina modeļus un, to darot, zināt, kā atsevišķi dizaina modeļi spēlē kopā.
- Risinājumam jābūt pielāgojamam, kas atbild uz pēdējo jautājumu no iepriekš uzbūvētā pamata analoģijas: pamatam jāspēj pielāgoties reljefam un grīdas plāniem. Kā jūs varat iedomāties, lai izveidotu pielāgojamo pamatu atšķirībā no standarta pamatiem, būtu vajadzīgs ļoti kvalificēts amatnieks.
Kopēji dizaina modeļi
Zemāk esošajā tabulā ir uzskaitīti daži izplatīti dizaina modeļi gan no J2EE avotiem, gan plašākiem OO modeļiem.
Kopēji dizaina modeļi
|
Apskatīsim divus J2EE dizaina modeļu piemērus: sesijas fasādes un vērtības objekta modeļus. Abi parāda, kā J2EE dizaina modeļi koncentrējas uz problēmām, kas īpaši saistītas ar J2EE vidi, atšķirībā no programmatūras izstrādes dizaina modeļiem, kas parasti attiecas uz visiem lietojumprogrammu izstrādes centieniem.
Piemērs: Sesijas fasādes J2EE modelis
Sesijas fasādes modelis izveidojās no pieredzes ar Enterprise JavaBeans (EJB). Sistēmas, kas izveidotas uz nesen ieviestajiem subjektiem EJB (kas sazinās ar datu bāzi), palēninājās līdz rāpošanai. Veiktspējas pārbaudē tika atklātas problēmas, kas izriet no vairākiem tīkla zvaniem, kas veikti, sazinoties ar entītijas EJB, kas pievienoja papildu izmaksas tīkla savienojuma izveidei, datu sērijveidošanai gan nosūtīšanai, gan saņemšanai un citiem efektiem.
Atbildot uz to, sesijas fasādes modelis uzlaboja veiktspēju, centralizējot šos vairākus tīkla trāpījumus vienā zvanā. Sesijas fasādē tiek izmantota bezvalstnieka sesija EJB, kas ir starpnieks starp klienta zvanu un nepieciešamo entītijas EJB mijiedarbību. Datu bāzes piekļuves veiktspējas uzlabošanai pastāv vairāk modeļu, tostarp ātrās joslas lasītāja un datu piekļuves objektu modeļi.
Piemērs: Value Object J2EE modelis
Value Object J2EE modeļa mērķis ir arī uzlabot to sistēmu darbību, kuras tīklā izmanto EJB. Tie, kas rada iepriekšējo piemēru pieskaitāmās tīkla sarunas, izgūst atsevišķus datu laukus. Piemēram, jums var būt Persona vienība EJB ar tādām metodēm kā getFirstName (), getMiddleName (), un getLastName (). Izmantojot vērtības objekta noformējuma modeli, šādus vairākus tīkla zvanus varat samazināt līdz vienam zvanam, izmantojot entītijas EJB metodi, piemēram, getPersonValueObject (), kas vienlaikus atgriež datus. Šis vērtības objekts satur datus, ko pārstāv entītija EJB, un tiem var piekļūt pēc vajadzības, neradot tīkla zvana pieskaitāmās izmaksas.
Piemērs: Flyweight OO modelis
Lai piemērotu plaši piemērotu OO dizaina modeli, apsveriet Flyweight modeli, kas uzlabo lietojumprogrammas veiktspēju, atkārtoti izmantojot objektu. OO programmatūra rada pieskaitāmus procesus - izšķērdētus procesora ciklus, atkritumu savākšanu un atmiņas sadali - kad tā rada un iznīcina objektu. Ja sistēma varētu atkārtoti izmantot šos objektus, jūs varētu izvairīties no šīs papildu izmaksas. Objekti bieži vien nav atkārtoti izmantojami, jo tie satur informāciju (sauktu Valsts), kas raksturīga objekta pašreizējam lietotājam. Flyweight modelis nodrošina pieejas šī stāvokļa pārvietošanai citur, lai pārējo objektu varētu izmantot atkārtoti.
Salieciet tos visus kopā: Neatlaidības piemērs
Tagad, kad zināt pamatus, varat sākt izmantot dizaina modeļus savā attīstības praksē. Bet kā jūs faktiski izmantojat modeļus? Vispirms identificējiet domēnu vai tehniskas problēmas, kurām nepieciešams risinājums. Noturība - veco objektu un relāciju datu bāzes neatbilstības novēršana - ir labs piemērs lielākajai daļai uzņēmuma lietojumprogrammu. Apskatīsim darbības, kas nepieciešamas, lai izveidotu un izveidotu lietojumprogrammas arhitektūras noturības slāni.
Ievērojot tradicionālo OO arhitektūras un dizaina pieeju, izveidojiet lietošanas gadījumus, aprakstot jūsu noturības vajadzības. Iespējamie lietošanas gadījumi ietver:
- Objekta noturībai jābūt pārredzamai no izstrādātāju viedokļa.
- Noturības mehānismiem - entītijas EJB, datu piekļuves objektiem utt. - jābūt konfigurējamiem arhitektūras līmenī.
- Mūsu arhitektūrai būtu jāizmanto J2EE tehnoloģijas, bet jāapkopo J2EE atkarības. Mums vajadzētu būt iespējai pilnībā mainīt J2EE lietojumprogrammu serveru piegādātājus, J2EE versijas vai pilnībā aizstāt J2EE, neprasot pilnu lietojumprogrammas remontu.
- Iegūtajam noturības slānim vajadzētu būt atkārtoti izmantojamam visos projektos. Tam vajadzētu būt daļai no mūsu pašreizējās lietojumprogrammu arhitektūras.
Kad esat identificējis problēmu, varat izlemt, kuri modeļi ir piemērojami. Atcerieties, ka J2EE modeļiem jums jānosaka, kuri modeļi tiek lietoti problēmas zonā, un tie jārisina. Lai nodrošinātu noturību, attiecīgie J2EE dizaina modeļi ir (skatiet Sun J2EE dizaina modeļu grāmatas resursos):
- Vērtības objekts
- Ātrās joslas lasītājs
- Datu piekļuves objekts
- Sesijas fasāde
- Salikta vienība
- Vērtību saraksta apstrādātājs
Tā kā jūs izmantosiet EJB, iekļaujiet biznesa delegātu un pakalpojumu meklētāja modeļus, lai risinātu EJB piekļuvi.
Turklāt, lai atrisinātu otro un trešo lietojumu, nepieciešami tradicionālie programmatūras izstrādes dizaina modeļi. Kā jūs iekapsulējat atkarības un jums ir konfigurējami noturības mehānismi? Daži piemērojamie programmatūras izstrādes modeļi ietver:
- Rūpnīca
- Starpnieks
- Stratēģija
