ASP.NET Dynamic Data Intro (2.)

Legutóljára ott hagytuk abba, hogy valahogy jó lenne az adatok validálását is jobban kézben tartani, valamint szeretnénk egyes táblák megjelenítését egyénire szabni. Ez a bejegyzés most az előbbi, validációs témába nyújt egy rövid betekintést.

ADO.NET Dynamic Data  – Bemeneti adatok validálása

Az előző alkalmazás mentén tovább a haladva, ha futtatjuk a projektet, és átnavigálunk a Customers táblához, egy sort szerkesztve láthatjuk, hogy megtehető, hogy a ContactName mezőt üresen hagyjuk és úgy updatelünk.

 
Validátor vezérlő (jelenesetben RequiredFieldValidator) nem kapcsolódik hozzá, mert az adatmodell semmilyen kényszert nem definiál az adott mezőhöz. Ugyanezt elkövetve a CompanyName mezővel a következő eredményt kapjuk:

 
Azaz a validátorok elhelyezése az adatmodellen definiált kényszerekhez köthető. A CompanyName property a Customers osztályban a következő attribútummal van ellátva: [global::System.Data.Objects.DataClasses.EdmScalarPropertyAttribute(IsNullable=false)]
Felmerül a kérdés, hogy az adatmodell megváltoztatásán túl lehet-e egyéb módszereket alkalmazni a validálás testreszabására. Gondolok itt a validáció típusára, a szöveg lokalizációjára, megváltoztatására, vagy akár eddig nem validált mezők validálására. A válasz természetesen egyértelmű igen! A validációt több szinten is végezhetjük:

1. Input szinten
   1. Metaadatokkal
2. Adatmodell szinten
   1. Property szinten
   2. Entitás szinten
   3. Contextus szinten

Validálás metaadatokkal input szinten

Készítsünk egy metaadat osztályt a Customers entitáshoz is, ahol konfigurálhatjuk a validációs mechanizmust.

1. RequiredFieldValidator

A ContextName mező kitöltése a Required attribútumnak köszönhetően kötelező, valamint a default "The ContactName field is requied" helyett  "A ContactName mezőt ki kell töltenie" üzenetet kapjuk az ErrorMessage beállításának köszönhetően.

2. RangeValidator

A Products osztályban a UnitsInStock property értéke csak 0 és 1000 közé eshet!

3. StringLenghtValidator

Jól jöhet, ha definiálhatjuk, hogy maximum hány karakter hosszú stringet rendelhetünk egy értékhez. Különösen kellemes, ha a Dynamic Data ennek megfelelően a TextBoxunk MaxLength property-jét is rögtön beállítja, azaz nem tudok X karakternél többet beírni a szövegdobozba. Ezt a StringLengthAttribute segítségével érhetjük el.

Jelen esetben az ErrorMessage még felesleges is hiszen, eleve nem tudunk 15 karakternél többet bírni a Country-hoz tartozó TextBox-ba! Erre a bizonyítékot a kirenderelt HTML-ben találhatjuk meg:

4. RegularExpressionValidator

A legrugalmasabb beépített validációs mechanizmus talán a reguláris kifejezés alapján történő validáció. Az alábbi példában a Shippers táblában található Phone mezőhöz füzök egy fix telefonszám formátumot (xxx) xxx-xxxx formában. Segítségemre a RegularExpressionAttribute siet.

A kimeneten pedig jól látszik az eredmény:

Validálás adatmodell szintjén

Időnként ennél is rugalmasabb validációra van szükség. A saját validációs logikát elhelyzetjük az adatmodellben is, akár több szinten.

1. Validálás Property szinten

Ha mindössze egyetlen property-t szeretnénk validálni megtehetjük a property-hez tartozó, helyesebben fogalmazva, a property setterében meghívásra kerülő parciális metódusokban. Vessünk egy pillantást a Customers osztály ContactTitle mezőjére:

Látjuk a setter-ben, hogy a _ContactTitle privát változó beállítása előtt meghívásra kerül az OnContactTitleChanging(string) metódus. Hol van ennek a metódusnak a definíciója? Néhány sorral lentebb látható: partial void OnContactTitleChanging(string value). Azaz a prototípus definiált, de implementálva nincs. Mivel partialként van megjelölve a meghívása nem okoz problémát, lehetőséget kapunk, hogy később implementáljuk ezt a metódust. Ezt tesszük meg most!

Ha a custom logikánk (amit egy RequiredAttribute-tal is kiválthattam volna, mindenki saját fantáziájára bízom, hogy milyen custom logikát alkalmazna itt) szerint érvénytelen az input, akkor egy ValidatonException-t eldobunk. Na jó, de ki kapja el? A válasz az adott pagetemplate-ben található!

Jól látható, hogy egy DynamicValidator helyezkedik el az Edit.aspx-ünkben, amely a DetailsView1-et igyekszik validálni. Na ő az, aki elkapja ezeket a ValidationException-öket és megfelelően kezeli. (Ismét valami, ami kész van, különösebb kódolás nélkül)

2. Validálás Entitás szinten (Linq To Sql)

Ha netán nem egyetlen property, hanem egy egész entitás szintjén szeretnénk validálni, erre is van lehetőség, mégpedig az
OnValidate(ChangeAction) parciáls metódus keretében (Linq To Sql adatmodellnél).

3. Validálás Contextus szinten (Entity Framework)

A contextus osztályunk (NorthwindEntities) rendelkezik egy OnContextCreated parciális metódussal, melyben feliratkozhatunk a SavingChanges eseményre, ahol az összes függőben levő változtatáson végigmazsolázhatunk, és saját validációs logika alapján akár ValidationException-t is dobhatunk. Ahogy korábban is, a kivételt a DynamicValidator kapja el és jeleníti meg.

Remélem ízelítőnek elég lesz ennyi a validáció testreszabásáról az ASP.NET Dynamic Data-ban. A következő bejegyzésben a táblák megjelenítésének egyéni testreszabásáról lesz szó.