1. Model View Controller disainimuster
Selle rakendamine Java internetirakendustes

2. 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

3. 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.

4. Lihtne näide
Bla bla bla..

5. 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.

6. 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.

7. 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

8. 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

9. 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

10. Controller3
Kuidas saab kleint teatada kontrollerile, millist operatsiooni sooritada? 1
edastada POST meetodiga peidetud vormi väli <FORM METHOD="POST" ACTION=" <INPUT TYPE="HIDDEN" NAME="OP" VALUE="createUser"/> ...
edastada see GET parameetrina
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

11. 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.

12. 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!!

13. 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

14. 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.

15. 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

16. 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

17. 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’

18. 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

19. Aitähh kuulamast!
Küsimused ?

20. PS MVC kohta võib netist leida ka kaunis kriitiliseid artikleid: