MVC
Model View Controller
Szoftver fejlesztés régen
• Console-based alkalmazások
• Pure HTML weboldalak
• Assembly, C
• Tipikusan kevés fejlesztő
• (Johm Carmack – Wolfenstein, Doom, Quake..)
• Szűkös erőforrások – optimális kód
Szoftver fejlesztés ma
• Rich alkalmazások (mobil, desktop)
• Komplex portálok – web appok
• Fejlett OO programnyelvek
• Akár több száz fejlesztő 1 projekten
• Bőven vannak erőforrások – nem kell többébyte szintű optimális kód
• Nincs többé univerzális programozó :
– Adatbázis programozó
– Field “know-how”-al rendelkező programozó
– Backed fejlesztő
– Frontend fejlesztő
– UX engineer
• Mindegyiknek bele kell nyúlnia a kódba
Szoftver fejlesztés ma
• Komponensek (modulok) újrahasználása
• Komponensek (modulok) kicserélése
• Programozási feladatok szétbontása
• Tesztelhetőség
Cél : Kód modulokra bontása
Ezekre a problémákra egy lehetségesmegoldás az MVC design pattern
MVC - eredet
• ’70-es évek végén a smalltalk nyelvben először(Xerox) – grafikus UI megjelenésekor
MVC - szárnyalás
• Az MVC a webes, illetve objective c (iOS) fejlesztések során kapott nagy figyelmet, ésnapjainkban is jelentősen meghatározza szintebármely GUI-val rendelkező szoftverfelépítését.
MVC - működés
• Az MVC három rétegre bontja az alkalmazást :
– Model (pl. adatbázis)
– View (amit a user lát – GUI)
– Controller (Összeköti a View-t a Model-el, gyakorlatilag a business logic található itt – azaz a modelt-t a UI bemeneteknek megfelelőenváltoztatja)
Miért pont model view controller?
• 1870-ben valaki írt egy novellát
– 1927-ben kiadták könyvben
– 1987-ben készítettek egy filmet róla
– 2002-ben kiadták hangoskönyvként
• 1 novella – 3 féle reprezentáció
Miért pont model view controller?
• Gyakran ugyanazt a problémáttöbbféleképpen lehet megjeleníteni
• Change requestek (finomítások, módosítások) leggyakrabban a UI kapcsán merülnek fel(experimentation)
• Gyakorlatilag szétválasztjuk a kódot amitartalmazza a problémát, attól, amimegjeleníti.
Működés
MVC frameworks – server side
– Zend Framework (PHP)
– Asp .NET MVC
– … Sok más
• Miért kell framework egy patternre?
Miért kell framework egy patternre?
• Kód standarizálása azáltal, hogy belekényszerítegy módszertanba (naming, layout, stb..)
• Platform függő nyelvi elemek megvalósítása –standardizálása, pl :
– Melyik class mikor hívódik meg
– Hogy működik a kommunikáció (technikailag) azegyes részek között.
Példa felépítés – szerver oldal
• Model classok
• Controller Classok
• View templatek
Példa felépítés – Model classok
• Adatbázissal való kommunikációért felelnek –update, select, stb.
• ORM-ek generálják tipikusan nekünk
• Lényegében az “adatbázis réteg”
Példa felépítés – Model classok
class User
{
private int _userId;
private string _firstName;
private string _lastName
public function setUserId(id:int);
public function getUserId(id:int);
public function setFirstName…
…
}
Gondoskodik az adatbázis kapcsolat felépítéséről, lebontásáról, mezőklekérdezéséről, updateléséről stb..
Példa felépítés – Controller classok
• Kívülről : URL-ek, pl. xx.hu/User
• Függvények user input lekezelésére pl.xx.hu/User/Update?id=12&firstName=B&lastName=C
• Lekezelik a user inputot, validálják a jogosultságot, updatelik a modelt.
Példa felépítés – Controller classok
class UserController
{
public function updateUserInfo(id:int,
firstName:String, lastName:String);
public function getUserInfo(id:int);
}
Mindem controller actionhöz (itt : függvény) tartozik egy view.
Példa felépítés – View templatek
• Minden actionhoz egy
• Általában : HTML template
• Lényegében kirajzolja a weblapot.
Példa felépítés – View templatek
getUserInfo.html.template
<html>
<head> Get User Info </head>
<body>
<%script user:User = viewData[“user”] %>
User Neve : <%script write user.firstName + user.lastName
%>
</body>
MVC alkalmazása desktop/mobilapp esetén
• Model classok
– Lokális-remote adatbázis, webservice-től kapottadat, stb..
• Controller Classok
• View Classok
Példa felépítés – View classok
• Rendkívül bonyolultak lehetnek
• UI fejlesztő szerepe
• Manapság rendkívüli fontosság
– (pl. Twitter kliensek – lényegében itt a különbség)
Tipikus mobil app – Dupla MVC
• Server side MVC – response XML-JSON formátumban
• Client side MVC
MVC alternatívák : MVP
• Model
• View
• Presenter– View és model
közti eseményekértfelelős
MVC alternatívák : MVP
• View nem ismeri a modelt.
• Presenter függvényeken keresztül manipuláljaa view – t (pl. setText)
• Könnyű view tesztelhetőséget eredményez(Test driven development hozománya) – csakaz interface kell a view-nak.
MVC alternatívák : MVVM
• Model
• View
• ViewModel
• Tipikusan Windows/XAML appokban,data binding okán
MVC alternatívák : MVVM
• A ViewModel nem generikus – minden View-nak van egy sajátja – arra épül, hogykiszolgálja a view-t.
• Lehet data bindingelni a ViewModel-t a view-hez – az majd updateli az adatbázist.
• Előny : A View-nak nem kell semmiről tudnia a ViewModel-en kívül (model változtatása nemhat ki rá), mégis lehet data binding-et alkalmazni.
Összefoglalás
• MVC is not magic, de egy jó irány a struktúráltkód felé
• Átláthatóvá, könnyen debuggolhatóvá, ésmódosíthatóvá teszi a kódot.
• Értsük meg, és használjuk ahol tudjuk
• Egyes frameworkök tanulási görbélye meredeklehet, de megéri az erőfeszítéseket.