ASP.NET Dynamic Data Intro (1.)

Rohant már oda hozzád rendszergazda azzal, hogy extra gyorsan kéne egy webes felület az adatbázisához, ahol a tábláinak az adatait tudja felügyelt módon szerkesztgetni, feltölteni? Vagy netán neked fejlesztési időben jól jött volna egy ilyen felület, ahelyett, hogy a management studio-t használtad volna ilyen célra? Esetleg jól jött volna intranetes alkalmazásodhoz egy olyan out-of-the box site, ahol a tábláid adatai automatikusan vizualizálásra kerülnek, rögtön szerkeszthető formában? Ha igen, akkor a dynamic data a neked való technológia!

Az ASP.NET Dynamic Data a .NET 3.5 SP1-ben került bemutatásra, és elsődleges célja, hogy egy adatmodell fölé épülve az entitásokat rugalmasan, testreszabható formában megjelenítse, és egyfajta CRUD-ot támogató felületet építsen fel dinamikusan. Ahelyett, hogy tovább elmélkednék a technológiáról, egy apró tutorial formájában inkább bemutatnám!

Visual Studio 2008-ban, mikor egy új Dynamic Data Page-et szeretnénk készíteni az első döntés, amivel szemben találjuk magunkat, hogy Linq To Sql által készített adatréteget, vagy inkább az Entity Framework által generált adatréteget kívánjuk használni!

A Dynamic Data Entities Web Application mögött ADO.NET Entity Framework dolgozik, míg a sima Dynamic Data Web Application mögött Linq To Sql. (Itt most az előbbit választom)

A következő lépés az adat modell elkészítése, ami alapján a Dynamic Data felépítheti dinamikusan az oldalakat. A projekthez egy új elemet kell felvennünk, még pedig egy ADO.NET entity data model-t!

1. Az entitás modell elkészítése

A wizard-on kiválasztjuk, hogy adatbázisból generáljuk az entitás modellt, beállítjuk, hogy a Northwind adatbázishoz szeretnénk csatlakozni. A web.config-ba pedig elmentjük a hozzá tartozó connection stringet!

A következő lépésben kiválasztjuk az összes táblát, így az Entity Framework az összes táblázhoz generál entitás osztályokat. A modell névtere a NorthwindEntities lesz.

A studio legenerálja az entitás modelt, mentsük el, majd be is zárhatjuk!

2. A Dynamic Data Site életrekeltése

Miután a modell kész, valahogy el kell érnünk, hogy a Dynamic Data ezt a modellt használja fel adatforrásként. Ezt a Global.asax fájlban tehetjük meg. A fájlt megnyitva elénk tárol a statikus RegisterRoutes függvény. Ahogy az igen bő komment is mondja, szűntessük meg a kikommentezést az alábbi soron, adjuk meg az adatkontextus típusát, illetve a ScaffoldAllTables tulajdonságokat false-ről állítsuk true-ra. Ezzel két dolgot értünk el. Az egyik, hogy a dynamic data most már tudja, honnan gyűjtse be az adatokat, illetve, hogy default-ból, minden táblát vizualizálnia kell. (ScaffoldAllTables)

Ezen a ponton futtathatjuk is az alkalmazásunkat! A szemünk elé tárul egy default témával ellátott oldal, ahol láthatjuk a tábláink listáját.

Bármelyik tábla nevére klikkelve a hozzá tartozó adatok megjelennek. Íme a Products tábla:

Kicsit nyaggatva, a következő dolgokat vesszük rajta észre…

1. A Lista szűrhető a fenti dropdownlist-ek alapján
2. Az oszlop fejlécére klikkelve rendezésre kerül a lista
3. Van edit, delete és details funkcionalitás
4. Új elem beszúrására találunk link-et
5. Szabályozható futásidőben, hogy hány elemet jelenítsünk meg egy oldalon
6. A Categories szekcióban CategoryID helyett, a kategória neve jelenik meg!!!
7. Minden postback aszinkron, azaz az oldalunk AJAX-et használ.
8. A Products táblából az asszociációkon keresztül könnyedén átnavigálhatunk egy másik táblára, pontosabban a másik táblában található, az adott sorhoz kapcsolódó adatokhoz.

Máris kaptunk egy csomó out-of-the-box funkcionalitást, pedig kódot még gyakorlatilag nem is írtunk.

Az edit, illeve az insert linkre kattintva sem kell csalatkozunk. A Editnél a barátságtalan SupplierID helyett, egy dropdownlistből választhatjuk ki a Supplier nevét. Továbbá, mind update és mind insert esetén kapunk validátor vezérlőket, amik ellenőrzik az adatok helyességét. Például ha valami az adatbázis szinten "not null", nem maradhat kitöltetlenül, ahhoz kapunk RequiredFieldValidator-t!

4. Mi történik?

Nem egyszerű kódgenerálásról van szó. Nagyon nem. A Solution Explorerben dalálható Dynamic Data mappára vessünk egy pillantást.

Nyoma sincs Products, vagy bármilyen más adattábla specifikus oldalnak. Valójában PageTemplate-ek vannak.

1. List.aspx – megjelenítés
2. Edit.aspx – szerkesztés
3. Insert.aspx – beszúrás
4. Details.aspx – adott sor részleteinek megjelenítése
5. ListDetails.aspx – Inline szerkesztés

Ha megnyitjuk az egyik ilyen aspx-et látjuk, hogy semmilyen tábla specifikus adat nincs benne, teljesen általános sablon dokumentumok. Sőt arra sem nagyon találunk semmi vonatkozást, hogy az egyes oszlopelemek hogyan jelennek meg.
Erre szolgálnak segítségül a FieldTemplate-ek. Itt az egyes típusokhoz tartozik egy-egy UserControl. Mind a megjelenítéséhez, mind az edit állapotához. Például a Boolean.ascx-ben egy egyszerű checkbox van. Azaz az egyes típusoknak egy UserControl felel meg, amit mi testreszabhatunk itt, vagy kicserélhetünk teljesen, netán új típusokat vezethetünk be.

Ha futtatjuk az alkalmazást és egy pillantást vetünk az URL-re, igazán érdekes dolgot tapasztalhatunk. A Products táblára klikkelve az alábbi címet láthatjuk:

Garantáltan nincs Products mappám, és a List.aspx sem tartalmaz semmi product specifikusat, az adat mégis helyesen jelenik meg.
Az egészért az ASP.NET Routing felelős. A Global.asax-be visszavándorolva a következő kódrészleteket találhatjuk még:

A fenti kódrészlet egy DynamicDataRoute-ot definiál, {table}/{action}.aspx formában, ahol az action lehet list, details, edit, és insert. Ez a kódrészlet határozza meg, hogy a Products/List.aspx értelmes URL legyen, és a products táblát tekintse aktuális entitásnak, amin a List.aspx sablon kerül alkalmazásra. Az engine elemzi a tábla adatait és a List.aspx-ben található sablon alapján megjeleníti az egyes adatokat, a típusuknak megfelelő usercontrolok alapján.

Láthatjuk, hogy nem mezei kódgenerálás történik, hanem egy jóval dinamikusabb oldalösszeállítás.

3. Testreszabás, avagy mit lássunk és hogyan?

Szép, szép, de hogyan lehet testre szabni? Hogyan zárhatok ki táblákat, oszlopokat a Scaffolding alól, ha nincs egy string, amit felül tudok definiálni, akkor hogy tudom megváltoztatni a nevét egy adott oszlopnak, vagy akár az egész táblának? Az entitás modellt kell módosítanom?

A modell kiegészíthető metadatokkal, amelyek segítségével a dynamic data a megjelenítést módosíthatja. Az entitás osztályaink partial-ként vannak megjelölve, így egy külső class fájlban nyugodtan írhatok hozzá ezt-azt. A metadatok attribútumok formájában kapcsolódhatnak az entitásokhoz és a tulajdonságokhoz. Ezek az attribútumok a System.ComponentModel.DataAnnotations névtérben találhatók meg. (külön dll-ben szerepel, más technológiák is adaptálhatják)

Nézzünk néhány egyszerű példát:

1. A Territories tábla kizárása a megjelenítésből. (Add new class: Territories.cs)
   Az entitás osztály fölé helyezve a ScaffoldTableAttribute-ot, false értéket átadva neki, kizárhatjuk a táblát a vizualizációból.

    

2. Oszlop kizárása – Products táblából a ProductID kizárása
   Ha tagokra kívánunk hivatkozni akkor szükségünk lesz egy osztályra, ami az entitások tulajdonságaival kapcsolatos metaadatokat írja le. Ezt követően az entitás osztályon jelezni kell, hogy melyik osztály tárolja a metaadatokat. Ezért definiálunk egy belső metadataosztályt, ahol az egyes property-kre hivatkozhatunk. A property típusa lehet object, ez a dynamic data-t nem érdekli. Mivel a ProductID-t zárnánk ki, ezért a ScaffoldColumn attribútumot állítjuk false-ra a ProductID property-n.

   

3. Oszlop átnevezése – UnitPrice oszlop átnevezése Price mezőre
   A metadata osztályban a UnitPrice mező elé a DisplayName attribútumot vesszük fel, ahol paraméterként megadjuk, hogy mostantól az mező neve mindenhol Price legyen.

   

4. Tábla átnevezése – Products tábla átnevezése Termékek táblára.
   A változás entitás színtű, így a Products Entitás osztályunkat értinti a DisplayName attribútum.

   

5. Értékek formázása – UnitPrice oszlopban található értékek megjelölése pénznemként
   A ProductMetadat osztályban a UnitPrice property fölé elhelyezzük a DisplayFormat attribútumot, a DataFormatString paramétere pedig legyen a {0:C} formázó string.

   

6. Dátum formázása
   A dátumok még az óra, másodperc információt is tárolják. Az Orders táblára klikkelve látjuk, hogy több oszlopban is szerepel ez a probléma. A megoldás nem az, hogy egyenként változatjuk meg a propertyk DisplayFormat-ját, hanem a típushoz (DateTime) tartozó usercontrol-on változtatunk. Ha megnyitjuk a DateTime.ascx-et a következőt látjuk. A FieldValueString tárolja a dátumot string formátumban.
    
   Ezt kell lecserélnünk az alábbira.

   

   Így az alkalmazásunkban az összes dátum formázásra került, hiszen mind ezt a usercontrolt fogja használni.

Na mára ennyi elég… 🙂 Folyt. köv.
A következő cikkben validáció testreszabásáról, illetve Custom Page-ekről (oldalak egyéni testreszabásáról) lesz szó.