Model View Controller disainimuster Selle rakendamine Java internetirakendustes

Model View Controller ühed andmed (model) mitu vaadet (view) “vahendajaks” on Controller Model View Controller on enimkasutatav muster kasutajaliideste juures. Kasutajaliides on põhimõtteliselt mingi mudeli/andmete presentation layer. Kui muutub mudel, peab uuendama view’d ja vastupidi – kasutaja tehtud muudatused peavad salvestuma andmetesse. Ühtedele andmetele võib olla mitu vaadet. Mudeli ja andmete vaheliseks “vahemeheks” on controller, mille ülesandeks on õige ‘View’ näitamine kasutajale ja kasutajatehtud muudatustele reageerimine (nupuvajutused, hiire click’id jne..) ning vajadusel teiste View’de muutmine vastavalt mudelis toimunud muudatustele. Model

Eritüüpi objekitd <<entity>> tavaliselt püsisalvestatavad objektid <<boundary>> kasutajaliides <<control>> kasutus-stsenaariumeid ellu viivad objektid Model View Controller tööpõhimõtte selgitamiseks võiks kasutada järgmiseid mõisteid: <<entity>> on pikaealised (üldjuhul püsisalvestatavad) objektid. See on informatsioon ja andmed, mida kasutajavormid näitavad. Näiteks andmebaasi tabelid, failid jne <<boundary>> objektid, mis asuvad süsteemi ja välismaailma vahel Nende kaudu suhtleb kasutaja süsteemiga. Nendeks on aknad, dialoogid, menüüd jne.. <<control>> objektid, mis kutsuvad välja mudeli ärimeetodeid ja valivad järgmise näidatava vormi // järgnevat pole vaja!! Reeglid: Kasutajad või “actor”id süsteemis suhtlevad ainult “boundary” obektidega “Boundary” objektid suhtlevad ainult controllerite ja “actor”itega “Entity” objektid suhtlevad ainult “controller”itega “Controllerid” võivad suhelda “boundary” objekide, “entity” objektide ja teiste “controllerite”ga, aga mitte “actoritega” Seega ainuke ligipääsupunkt kasutaja jaoks süsteemile on nn “boundary” objektid. “Boundary” objektid ei saa suhelda omavahel. “Controller”id võivad suhelda kõigi teiste objektidega välja arvatud süsteemi kasutajaga. “Entity” objektid ei saa suhelda omavahel vaid ainult läbi “controller” objektide. Seega “controller” on nn. vahemeheks kõigi kihtide vahel.

Lihtne näide Bla bla bla..

Rakenduse veebi-kihi disain Javas MVC on Java ametlik soovitus interaktiivsete rakenduste arhitektuuri disainil. MVC eelised: hoiab lahus erinevad disaini probleemid vähendab koodi dubleerimist tsentraliseeritud juhtimine lihtsustab rakenduse muutmist tagab rakenduse erinevate osade arendajate sujuvama töö Sun soovitab ametlikult kasutada interaktiivsete rakenduste arhitektuuri disainimisel Model View Controller mudelit. Seda kasutab ka enamus laialt pakutavaid Java veebikihi rakenduste raamistikke (näiteks Apache Struts). Java mõistes tegeleb aga nn. business loogikaga just mudeli kiht – controller valib lihtsalt järgmise näidatava pildi ja edastab andmeid mudeli ja kasutaja interface’i vahel MVC eelised: eraldab disaini probleemid – st, et erinevad kihid tegelevad andmete püsisalvestamise, presentatsiooni ja üldise rakenduse kontrolliga koodi dubleerimise vähendamine – tuleneb tsentraliseeritusst. Näiteks järgmise vormi valimise loogika on ühes kohas, mitte laiali kõigis kasutajavormides kogu rakenduse juhtimine toimub ‘control’i kihis kuna rakendusi ei tehta tavaliselt kohe algusest lõpuni valmis on oluline, et nende muutmine oleks lihtsam kuna suuremate rakenduse juures töötavad arendajad on tavaliselt spetsailiseerunud mingile kindlale rakenduse aspektile (näiteks äriloogika kirjutaja, kasutajaliidese disainer jne) siis on oluline, et nad saaksid pühenduda just arendatavale küsimusele ja ei peaks tundma kogu rakenduse kõiki aspekte MVC aitab tsentraliseerida kogu rakenduse turvalisuse, logimise ja nn ‘screen flow’ga seotud küsimused. Lihtsustab uute ‘data source’ide ja kliendi tüüpide lisandumist.

Model 1 vs. Model 2 Ametlikult enam ei eksisteeri Model1 ja Model2 disaini Model1 ja Model2 disaini terminid on pärit Java veebirakenduste vanast/esialgsest dokumentatsioonist ja neid mõisteid ei ole enam uues dokumentatsioonis, kuid nad on endiselt kasutuses “rahvasuus”. Model1 ja Model2 vahe on põhimõtteliselt ainult see, et Model1 korral puudub vahepealne kontroller servlet, mis Model2 mängib dispetsheri rolli – võtab vastu ksutaja päringud ja vahendab need mudelile ning valib välja järgmise view. Seega Model1-s jsp lehed ise pöörduvad ‘mudel’i poole Model2-s on vähendatud komponentide omavahelist sõltuvust – JSP-lehed ehk view’d ei viita enam üksteisele. Uue (sobiliku) view valib kasutaja päringu põhjal välja controller-servlet Seega soovitatav on kasutada nn. Model2 arhitektuuri. Model1 lahendust soovitatakse kasutada vaid VÄGA väikeste ja staatiliste rakenduste puhul.

Model-View-Controller Javas Mudel: kapseldab rakenduse seisundi siin on rakenduse funktsionaalsus algatab view’de muutmist View: ”Näitab” mudelit – ehk siis mudelist pärinevaid andmeid Edastab kasutaja tegevuse kontrollerile Lubab kontrolleril valida järgmist näidatavat view’d Controller: Määrab rakenduse käitumse Seob kasutaja tegevused ja mudeli uuendamise Määrab näidatava View

Controller1 Keskne pöörduspunkt Tüüpiliselt realiseeritud servletina Seab päringud vastavusse mudeli operatsioonidega Kontrollib ‘screen flow’d – valib kasutajale saadetava vastuse (JSP) Kuna controller on rakenduse keskne koht, siis on loogiline paigutada security jms, just controllerisse. Controller on tavaliselt realiseeritud servlet’ina Controller käivitab päringu täitmiseks vajalikke operatsioone rakenduse mudelis (beanid) Controlleri ülesandeks on välja valida ka klindile saadetav vastuse vorm. See sõltuv: eelmisest view’st mudelis käivitatud operatsioonide tulemustest võimalikest sessiooni muutujatest: PageContext, ServletRequest, HttpSession ja ServletContext

Controller 2 Kontroller võtab vastu kliendi päringu Loob uue Action tüüpi objekti Käivitab Action’i, mis omakorda pöördub mudeli ärimeetodi poole Kontroller käivitab uue view valimise “Pildihaludr” teeb kindlaks uue view ja tagastab selle nime kontrollerile Konroller edastab selle “templating service”’le Template’ing service on vajalik, et tagada ühtne stiil

Controller3 Kuidas saab kleint teatada kontrollerile, millist operatsiooni sooritada? 1 edastada POST meetodiga peidetud vormi väli <FORM METHOD="POST" ACTION="http://myServer/myApp/myServlet"> <INPUT TYPE="HIDDEN" NAME="OP" VALUE="createUser"/> ... edastada see GET parameetrina http://myHost/myApp/servlets/myServlet?op=createUser servlet mapping <servlet-mapping> <servlet-name>myServlet</servlet-name> <url-pattern>*.do</url-pattern> </servlet-mapping> .... kõik päringud suunatakse ümber ühele servletile. URL’i lõppu kasutatakse pärast küsitud operatsiooni teada saamiseks Viimase meetodi korral on veebirakenduse toodud xml pärit veebirakenduse ‘deployment descriptorist’ ja kõik *.do algusega päringud suunatakse ‘myServlet’ile. URL’i ülejäänud osa kasutatakse soovitavast operatsioonist teada saamiseks Ametlik soovitus on kasutada viimast versiooni, kus mingile mustrile vastav URL seotakse kindla servletiga, kuna see on kõige paindlikumat lahendust päringute suunamiseks

Controller4 Kuidas käivitab kontroller õige operatsiooni? 1/2 // Action.java: public abstract class Action { protected Model model; public Action(Model model) { this.model = model; } public abstract String getName(); public abstract Object perform(HttpServletRequest req); }; // CreateUserAction.java: public class CreateUserAction extends Action { public CreateUserAction(Model model) { super(model); } public String getName() { return "createUser"; } public Object perform(HttpServletRequest req) { return model.createUser(req.getAttribute("user"), req.getAttribute("pass")); } } Nüüd peab kontroller oskama välja kutsuda mudeli õiget operatsiooni. Pika If (op== “opName”) then model.opName() bloki kasutamine oleks tobe, ses tmuudaks ühe meetodi ebanormaalselt pikaks (nn. makaronikood) ja poleks ka laiendatav Parem on kasutada abstraktset klassi ‘Action’, millel on meetod perform() ja seda siis konkreetsest klassist polümorfismi teel välja kutsuda.

Controller5 Kuidas käivitab kontroller õige operatsiooni? 2/2 public class ControllerServlet extends HttpServlet { private HashMap actions; public void init() throws ServletException { actions = new HashMap(); CreateUserAction cua = new CreateUserAction(model); actions.put(cua.getName(), cua); //... create and add more actions } public void doPost(HttpServletRequest req, HttpServletResponse resp) throws IOException, ServletException { // First identify operation "op" from URL. getOperation() is defined elsewhere. String op = getOperation(req.getRequestURL()); // Then find and execute corresponding Action Action action = (Action)actions.get(op); ... action.perform(req); … Init() meetodis pannakse HashMap() objekti kõik võimalikud operatsiooni nimed ja siis sellele vastavad “Action” objektid. Seda võib põhimõtteliselt teha ka näiteks välise XML faili abil – ei pea kirjutama makaronikoodi :P Meetod getOperation() korjab ette antud URL’ist välja operatsiooni nime – see on kirjeldatud mujal ja siis käivitab perform() meetodi Siin on vaid koodi väljavõtted!!

Controller 6 Kuidas valib kontroller järgmise View? ScreenFlowManager konfigureeritakse XML-failist <url-mapping url="signoff.do" screen="signoff.screen"> <action-class> com.sun.j2ee.blueprints.petstore.controller.web.actions.SignOffHTMLAction </action-class> </url-mapping> Järgmise view valikut mõjutab praegune view, sooritatud operatsiooni tulemus ja võimalikud sessiooni objektide väärtused. Selleks kasutab ta xml-faili, mis seab vastavusse sooritatud ‘Action’ klassi ja uue view

Controller näite diagramm 1. The servlet container routes the request to the controller. 2. The controller creates an instance class SignoffHTMLAction and passes the request to it. 3. The controller calls the SignoffHTMLAction's perform method. 4. The SignoffHTMLAction object calls the model method that signs the user out of the application. 5. The controller asks the screen flow manager for the next view. 6. The controller forwards the request to the URL signoff.screen. 7. The templating servlet generates and delivers the requested view (a templated JSP page) to the client, so the user receives a view indicating that signoff succeeded.

Controllerid eri tüüpi klientidle Et teenindada erinevaid kliente, peab iga kliendi tüübi jaoks tegema eraldi kontrolleri. Kasutatav äriloogika aga jääb samaks. Ühise turvamudeli ja muu kõigile klintidele ühiste osade jaoks võib kasutada ühtset protokolli ruuterit

View View näitab andmeid kasutajale mudeli andmeid Ühtse stiili saavutmaiseks kasutatakse malle (templating) Tavaliselt on View’deks JSP-lehed, aga võivad olla ka HTML lehed või hoopis PDF-failid vms. JSP-d on parimad, et genereerida tekstipõhiseid andmeid. Servelette kasutatakse binaarsete andmete korral või varieeruva struktuuriga sisu korral. Templatinguga saavutatakse ühtne väljanägemine lehele. Kõik lehe osad on eraldi komponendid Sellega tsentraliseeritakse ka lehe disain – muutes template’i muutub kohe kõigi lehtede väljanägemine Samuti on näiteks menüü kasutuses ühes kohas (template’s) aga mitte copy-paste meetodil igas komponendis eraldi

Model Mudel sisaldab andmeid Mudel rakendab äriloogikat Mudel realiseeritakse sageli EJBdena Lihtsamate rakenduste korral võib kasutada ka lihtsalt JavaBean’e Mudel on sõltumatu kliendi tüübist JavaBean’id pakkuvad kiiret ligipääsu andmetele, samas kui EJB’d annavad ligipääsu ‘shared business logic and data’

MVC-st saadav tulu Eraldatud äriloogika ja kasutajaliides ning tsentraalne rakenduse juhtimine kasutajaliidese muutmine ei muuda äriloogikat ja vastupidi kogu äriloogika on ühes kohas, mitte laiali üle erinevate komponentide sõltumatus kliendi tüübist eraldatud arendajate rollid uus kujundus ei tähenda veel uue rakenduse ehitamist copy-paste on saatanast :P sama äriloogika rakendub nii brauserikliendile kui ka veebiteenuse kasutajale. Veelgi enam, äriloogika, mis on kirjutatud JSP-des scriptletina ei ole kasutatav teiste servletide poolt kasutajaliidese disaineril ei ole vaja mõista äriloogika koodi ja vastupidi – programmeerija ei tee tavaliselt ilusat lehte :P

Aitähh kuulamast! Küsimused ?

PS MVC kohta võib netist leida ka kaunis kriitiliseid artikleid: http://today.java.net/pub/a/today/2003/12/11/mvc.html?page=1