132 •
Maintainability: The separat ion of present at ion and business logic
al so makes it easier t o maint ain and modif y a St rut s-based Web appl icat ion.
T he Model
The model encapsul at es t he f unct ional core of an appl icat ion, it s business l ogic. The goal of MVC is t o make t he model independent of t he view and
cont rol l er which t oget her f orm t he user int erf ace of t he appl icat ion. An obj ect may act as t he model f or more t han one MVC t riad at a t ime.
Since t he model must be independent , it cannot ref er t o eit her t he view or cont rol l er port ions of t he appl icat ion. The model may not hol d direct
inst ance variabl es t hat ref er t o t he view or t he cont rol l er. It passivel y suppl ies it s services and dat a t o t he ot her l ayers of t he appl icat ion [ Tai04] .
T he View
The view obt ains dat a f rom t he model and present s it t o t he user and represent s t he out put of t he appl icat ion. It general l y has f ree access t o t he
model , but shoul d not change t he st at e of t he model . Views are read onl y represent at ions of t he st at e of t he model and read dat a f rom t he model
using query met hods provided by t he model
T he Cont roller
The cont rol l er component isol at es how a user’ s act ions on t he screen are handl ed by t he appl icat ion. This al l ows f or an appl icat ion design t o f l exibl y
handl e t hings such as page navigat ion and access t o t he f unct ional it y provided by t he appl icat ion model in t he case of f orm submissions. This
al so provides an isol at ion point bet ween t he model and t he view. Because t he cont rol l er component handl es t he user request s and invokes f unct ions
on t he model as necessary, it al l ows f or a more l oosel y coupl ed f ront and back end. Int eract ion bet ween t he model and t he view is onl y t hrough an
event -based mechanism t hat inf orms t he view of changes t o t he model ’ s dat a [ Bro03] .
3. J2EE Platform
The J2EE pl at f orm specif ies t echnol ogies t o support mul t it ier ent erprise appl icat ions. These t echnol ogies f al l int o t hree cat egories: component ,
service, and communicat ion. The component t echnol ogies are t hose used by devel opers t o creat e t he essent ial part s of t he ent erprise appl icat ion,
namel y t he user int erf ace and t he business l ogic. The component t echnol ogies al l ow t he devel opment of modul es t hat can be reused by
mul t ipl e ent erprise appl icat ions. The component t echnol ogies are support ed by J2EE pl at f orm’ s syst em-l evel services. These syst em-l evel
services simpl if y appl icat ion programming and al l ow component s t o be cust omized t o use resources avail abl e in t he environment in which t hey are
depl oyed [ Sin02] .
Appl ying a Model View Cont rol l er Pat t ern in J2EE Plat f orm Using St rut s Framework
Niko Ibrahim
133 Since most ent erprise appl icat ions require access t o exist ing ent erprise
inf ormat ion syst ems, t he J2EE pl at f orm support s APIs t hat provide access t o dat abases, ent erprise inf ormat ion syst ems such as SAP and CICS, and
services such as t ransact ion, naming and direct ory, and asynchronous communicat ion. Final l y, t he J2EE pl at f orm provides t echnol ogies t hat
enabl e communicat ion bet ween cl ient s and servers and bet ween col l aborat ing obj ect s host ed by dif f erent servers.
Figure 3 shows t he basic archit ect ure of J2EE pl at f orm:
Figure 3: Basic J2EE Archit ect ure 3. 1.
The Client Tier
From a devel oper’ s point of view, a J2EE appl icat ion can support many t ypes of cl ient s. J2EE cl ient s can run on l apt ops, deskt ops, pal mt ops, and
cel l phones. They can connect f rom wit hin an ent erprise’ s int ranet or across t he Worl d Wide Web, t hrough a wired net work or a wirel ess net work
or a combinat ion of bot h. They can range f rom somet hing t hin, browser- based and l argel y server-dependent t o somet hing rich, programmabl e, and
l argel y sel f -suf f icient . From a user’ s point of view, t he cl ient is t he appl icat ion. It must be usef ul ,
usabl e, and responsive. Because t he user pl aces high expect at ions on t he cl ient , we must choose our cl ient st rat egy caref ul l y, making sure t o
134 consider bot h t echnical f orces such as t he net work and non-t echnical
f orces such as t he nat ure of t he appl icat ion [ Bro03] .
3. 2. The Web Container
