KORÁBBI CIKKEK
CÍMKEFELHŐ
RAID
software raid
smarty
template
JSON
javascript
data-changing
MVC
design pattern
autoload
svn
ubuntu
apache
subversion
dav
php5
memcache
memcached
load
caching
post
cheat
php
no multipart
files
tgz
server
sh
bash
mysql
dump
mysqldump
backup
cli
daemon
PEAR
system_daemon
directadmin
magyarosítás
DA
enhanced
open source
nyílt forrás
közösség
Neelie Kroes
importance of communities
general
protection
general protection
segmentation
fault
segmentation fault
január 13 00:42:05, 2009
Mi is az MVC? Mint azt láthatjuk is, három szóból tevődik össze a dolog, melyek mindegyikének önálló jelentése van: Modell, View, Controller. Ez egy architektúrális minta, mely 1979-ben született, s azóta is számos területen bizonyított. Sokszor van úgy, változtatni szeretnénk az adatkezelésen, és nem szeretnénk, hogy ez érintse a felhasználói felületet. Az adathozzáférés és az ún. üzleti logika elválik egymástól egy köztes komponens bevezetésével, melyet Controller-nek hívunk. Vegyük sorra, melyík micsoda a modellben...
MODELEbben a részben fogalmazódik meg az üzleti logika. Ezen réteg feladata leírni az adatszerkezeteket (melyeket használni fogunk az alkalmazásban) és definiálni azokat a szabályokat, melyek alapján elérhetjük azokat. Amennyiben az alkalmazásunk valamilyen adatbázisból szedi elő az adatokat (az esetek többségében) és ezt változtatjuk szerkezetileg, vagy netán kicseréljük (pl. Oracle helyett legyen MS-SQL), akkor jobb esetben csak ezt a réteget kell módosítanunk, s ami mégfontosabb, nem vonja magával a user interface változtatásának szükségét.
VIEW
Ez itt a megjelenítéssel/prezentációval kapcsolatos osztályokat írja le, s itt mutatkozik meg az MVC igazi ereje, vagyis szeparálódik a prezentáció az adatoktól. A View dolga a Model teljes tartalmának vagy egy részének prezentálása. A legfontosabb alapszabály: az adatokat csak a Model osztályainak példányain keresztül érhetjük el és módosíthatjuk! Ezt az elvet a helyes tervezés érdekében muszály követni, s a lényeg még csak most jön, ha idáig követtük ezt a gondolatmenetet, akkor az eredményt bármilyen felületen keresztül, legyen az böngésző, mobil eszközök, bármilyen tartalmat előállíthatunk a modell alapján. A feladat mindössze annyi, hogy egy-egy View-ot készítünk mindhez, melyek ugyanazzal a modellel fognak dolgozni.
CONTROLLER
Itt a lényege az egésznek. Ok, hogy van Model és vannak View-k, de ezeket össze kellene kötni valahogy. Ezért felel a Controller. Az eseményeket, mint pl. kattintás egy gombra, bill. leütés... átfordítja egy a modell által végrehajtandó akcióra, illetve az akció lefutásának eredményétől függően megjeleníti a megfelelő View-t. A Controller nem mindig van külön megvalósítva, előfordul néha a gazdag kliens alkalmazások esetében, hogy összeolvad a View-al.
Röviden és tömören ennyit az MVC-ről. Rengeteg előnye van a dolognak, mint pl. az üzleti logika elválik az interakciós logikától (lsd. WPF codebehind fájl első comment). Az alkalmazás egyes részei jól elhatárolódnak egymástól, ezáltal újrafelhasználhatóvá válik a kód, s nem utolsó sorban mindez a csapatmunkát is elősegíti, mindenki a saját feladatára összpontosíthat, a másikra történő túlságosan erős ráutaltság elkerülhető vele. Egyetlen hátránya, hogy jól meg kell tervezni egy nagy adag osztályt, amik ezt az elhatárolódást szavatolják és nyilván sokkal több időt igényel, de ez a végén busásan megtérül, arról nem is beszélve, hogy szépen mindennek meglesz a helye, nem kell elveszni a nagy összevisszaság áradatában.
HOZZÁSZÓLÁS, VÉLEMÉNYEK