A multkori eszmefuttatásom az alkalmazástervezésről és általános struktúráról felvetett egy igencsak érdekes és viszonylag gyakran előkerülő kérdést, amire a válasz nem mindíg triviális. Ha már részt vettél egynéhány projektben, akkor biztosan felmerült benned a kérdés hogy a validáció egy MVC alkalmazásban vajon hova is tartozik?

A validálás áthatja az alkalmazás teljes architektúráját, a működés minden pontjához kapcsolódik valamilyen formában. Emiatt nem is szabad beskatulyázni ezt az igen fontos aspektusát a tervezésnek egyik, vagy másik rétegbe. Mint mindíg, itt is a józan logika diktálta hozzáállás bizonyulhat a legjobb megoldásnak. A tárgyalt architektúra nem dogma, hanem irányelvek jól összerakott halmaza. Igyekezzünk a validálás esetében is minél inkább megmaradni ezen irányelvek között.

A validációt két részre érdemes osztani:

1. Formátum-validáció
2. Szemantikus validáció

A formátum-validáció alatt értem mindazokat az ellenőrzéseket, amelyek az ellenőrizendő adat tulajdonságaira, reprezentációjára vonatkozik. Ezek közé tartozik például a típusvalidáció (string, integer, boolean, stb...), hossz vagy egyéb formai tuljadonság ellenőrzése, esetleg hogy nem tartalmaz ártalmas részt (pl. XSS egy webalkalmazásban).

A szemantikus validáció pedig minden olyan logikai ellenőrzés, amely az adat érvényességének, konzisztenciájának az ellenőrzése. Ilyen lehet pl. egy bankszámlakezelő szoftverben annak ellenőrzése, hogy a végrehajtandó tranzakció eredményeként nem lehet 0 alatt a számla összege.

A szemantikus ellenőrzést mindenképpen magában az üzleti logikát megvalósító komponensben érdemes végrehajtani (ami természetesen a Model rétegben helyezkedik el). Így a komponens képes "megvédeni magát", képes biztosítani, hogy az általa végzett művelet nem vezet inkonzisztenciához vagy téves működéshez az adat hibája miatt. Ebben az esetben lehet például kivételeket dobni, amennyiben előfordul valamilyen hiba. A Controller rétegben pedig lehet kezelni ezeket a hibákat. Így a Controller nem felel az ellenőrzésért, viszont a feladatát elláthatja, ti. hogy továbbítja a hibát a View rétegnek, amely megjeleníti a felhasználónak. Persze az sem kizárt hogy a Model rétegben egymást hívó rétegek elkapják az Exception-t mert mondjuk visszaállítható hibáról van szó, de ez így van jól, hiszen erről a felhasználónak nem kell tudnia, így a Controller rétegnek sem.

A formátum ellenőrzését praktikus elvégezni az adat beérkezésének helyén, ez lehet akár a Controller réteg is (persze mértékkel). Természetesen ha a validáció extenzív, akkor helyezzük át a Model rétegbe és hívjuk a Modelben levő validátorokat a Controllerből.

Ehhez jelenthet segítéget a Validator helper, egy egyszerű specializált tervezési minta. Ennek helye rendszerint a Modelben van. Lényege hogy a validációs feladatokat egy ilyen helper vagy util osztályba rakjuk és a Controllerben átvezetjük a Validatorunkon az adatokat, majd ha ez hibamentesnek találta az adatokat, akkor átadjuk az üzleti logikának.

class My_Controller
{
  public function indexAction() 
  {
    $data = new DataVO($_POST['data1'], $_POST['data2']);
    $validated = DataValidator::validate($data);
    $logic = MyLogic($data);
    $logic->executeTransaction();
  }
}

Ennélfogva lehetőségünk van külön validator facadeket csinálni a Logic különböző felhasználásaihoz és így a logikát függetlenül tarthatjuk a felhasználás helyének sajátosságaitól.

Természetesen nem kötelező Value Objecteket használni, bár ha már kiszervezzük az ellenőrzést egy validator helperbe, akkor valószínüleg akkora számú paramétert kell vizsgálni, amely indokolja a használatát.