Android – MVC vs MVP

Nincs miért ecsetelni a fejlesztési minták fontosságát. Ha az embernek van ideje, és nem egy meglévő kódot kell foltozni, akkor érdemes eleve egy rendezett vonalra “felfűzni” a munkát. Az Android esetében sincs ez másképp, és miközben példákat keresgéltem a Model-View-Controller megvalósítására, azt találtam, hogy egy kicsit másra van szükség. Az igazi megoldás az MVP (Model-View-Presenter)

Elég sok írást találtam mind az MVC, mind pedig az MVP minta Androidos felhasználásával, valamint ezek összevetésével kapcsolatban. A legrövidebb, ennek ellenére talán legkönnyebben átlátható elemzés (ami egyébként nem kifejezetten Android oldalról közelít a témához).

Megpróbálom a legtömörebben megfogalmazni a lényeges különbségeket (az alábbi ábra segíteni fog).

Amint látható, az MVC esetében a Controller kvázi “semmit nem tud” a View-ról, és az alapvető koncepció az, hogy a View alatt könnyen cserélhető a Controller, valamint egy Controller-t több különböző View is használhat. Látható, hogy a View frissítését a Model-ben történő változások idézik elő. (A View fel van iratkozva a Model különböző állapotváltozásaira. )
A minta egyik hátránya a unit-teszteléssel kapcsolatos (pontosabban annak nehézségével): a Controller manipulálja az adatokat, de a View szemszögéből nézve ezek a változások nem láthatók közvetlenül. Például a felhasználó klikkel valahol a felületen, így elindít egy eseménykezelést a Controller-ben, amelynek hatására megváltozik a Model-ben lévő egyik érték. Ezen értékváltozás, teszem azt, egy betűméret növekedést okoz a View-n. Az ilyen közvetett, háromszereplős esetek unit-tesztelése kissé problémás.

Az MVP esetében a Presenter “visszakommunikál” a View felé, ellentétben a Conroller-rel. A Model pedig nincs közvetlen kapcsolatban a View-val, bármi változás történik, először a Presenter értesül róla, ami aztán frissíti a View-t. Ez segít a mock-olásban és könnyebbé teszi a unit-tesztelést is, hiszen minden esetben pontosan két szereplő közti kapcsolattal kell foglalkozni.

A fent leírtak mellett többek között azért döntöttem az MVP alkalmazása mellett, mert úgy látom, hogy annak alapelvei fedik le inkább az Android architektúrát. Gondoljunk csak az Activity osztályra, amiről, ha MVC-t alkalmazunk, sokszor nem lehetne eldönteni, hogy View vagy Controller. Az MVP mintában viszont a View számára nem ördögtől való az (sőt!) hogy bizonyos logikai funkciókat is végrehajtson, ahogyan a Presenter-ben is előfordulhatnak a megjelenéssel kapcsolatos kódrészletek. Az MVP-nek két típusát különböztethetjük meg az alapján, hogy a Presenter helyett mennyi logikát valósítunk meg a View-ban:

- Passive View: A lehető legminimálisabb feladatokat látja el, gyakorlatilag a “nem csinál semmit” állapothoz van legközelebb. A Presenter nem csak lekezeli a felhasználó által előidézett eseményeket, de teljes mértékben ő felelős a View frissítéséért is.

- Supervising Controller: (talán logikusabb lenne Supervising Presenter-nek hívni, ha már MVP, ugye. ) A megjelenéshez kapcsolódó egyszerűbb feladatokat a View-ban hagyjuk, és a Presenter – ahogy egy Controller-hez illik – valóban csak a logikáért felel.

Joggal mondhatnánk, hogy a Supervising Controller verziót választva fennáll a veszélye annak, hogy éppen azt az alapelvet rúgjuk fel, ami miatt egyáltalán MVC vagy MVP mintákat alkalmazunk. Hiszen hagyjuk, hogy logika maradjon a View-ban, és megjelenítéssel kapcsolatos kód is maradhat a Presenter-ben. (Ez egy olyan felvetés, ami bennem is felmerült, és nagyon kíváncsi vagyok, ki, mit gondol, mert egy hangyányit engem is elbizonytalanít. )
Ugyanakkor azt gondolom, hogy a “való világban” tényleg nem lehet, és talán nem is érdemes mindig, ész nélkül, mereven ragaszkodni a keretekhez. Cannot turn off passcode lock best tracker phone on iphone or ipad apple tv screensaver, photo albums, and videos related stories will removing a credit card from safari also remove it from apple pay. Igenis lehetséges, hogy bizonyos kódrészletek – józan paraszti ész szerint – nyugodtan maradhatnak a View-ban, mert bár szigorú értelemben véve logikát valósítanak meg, ugyanakkor annyira egyértelműen az adott megjelenítéshez kötődnek, hogy ott a legindokoltabb őket elhelyezni.

A  - és persze majd magát a fejlesztést is – az MVP minta alkalmazásával kezdem meg, azt hiszem jó tanulópálya lesz.

Addig is, akit érdekel, olvashat egy Android-MVP példaprogramról.

.

Kategória: Általános | A közvetlen link.