Informatikai technológiák laboratórium 1 - AUT 2. mérés: Entity Framework

← Vissza az előző oldalra – Informatikai technológiák laboratórium 1

Hasznos linkek

Informatikai technológiák laboratórium 1. AUT-os tárgyoldala:

http://www.aut.bme.hu/Portal/Targy.aspx?courseId=3d7b71f0-ca1b-48f4-adfd-cffeb4e26031

Adatvezérelt alkalmazások fejlesztése tárgyoldal

http://www.aut.bme.hu/Portal/aaf

1. Sorold fel az Entity Framework három leképzési rétegét! (2p.)

• Conceptual Model
• Map
• Storage/Logical Model

Leíró nyelveik sorrendben:

• Conceptual Schema Definition Language (CSDL)
• Mapping Specification Language (MSL)
• Store Schema Definition Language (SSDL)

2. Milyen lehetőségek vannak Entity Frameworkben egy osztály adattáblákra való leképzésére? (2p.)

• Egy hierarchia egy táblába | Table per Hierarchy (TPH)
• Minden típus saját táblába | Table per Type (TPT)
• Minden valós osztály saját táblába | Table per Concrete Type (EDM Designer nem támogatja)

3. Mit jelent a „lazy loading”, milyen szerepet kap az Entity Frameworkben? (2p.)

Lazy loading esetén csak akkor töltjük be az objektumot amikor valóban szükség van rá. EF-ben az entitások betöltése lehet explicit (IsLoaded, Load, tehát kezdeményezni kell) vagy implicit (automatikusan történik navigation propertyk mentén).

Másik lehetőség az Eager loading, ami a kért navigációs propertykhez tartozó entitásokat is automatikusan betölti.

4. Az Entity Framework 3 alapvető módszert kínál az entitások elérésére. Melyek ezek? (2p.)

• LINQ to Entities
• Entity SQL with Entity Client
• Entity SQL with Object Services

5. Miért jelentenek nehézséget az ORM rendszerek szempontjából a 3, vagy többrétegű alkalmazások a hagyományos 2 rétegű alkalmazásokkal szemben? (2p.)

Mert az entitás kikerül az ObjectContext alkalmazástartományából és így az állapotkövetés nem bízható rá. A változásokat explicit kell az OC tudomására hozni. A kliensnek minden adatot szolgáltatnia kell a módosításokhoz. -> ez itt most EF specifikus, diáról, X

6. Milyen problémára és hogyan ad választ a „self-tracking entity” megoldás az Entity Frameworkben? (2p.)

• Diák alapján*: Többrétegű alkalmazások esetén az állapotkövetést nem bízhatjuk az ObjectContextre, ezért nem használhatjuk az alapértelmezett EntityObject-et. A "self-tracking-entity" programozási modellje azonos a hagyományos EF-fel, kiegészítve állapotinformációkkal.

• Másképp*: n-tier alkalmazásoknál nincs közvetlen kapcsolat pl. a kliens (Silverlight alkalmazás) és a szerver, DB között.

Ezért valahogy meg kell oldani, hogy amit a kliens csinál változásokat, azokat a szervernek a tudtára kell adni. Így az STE az rögzíti a saját változásait és amikor a szerverhez visszaküldjük, akkor a szerver tudni fogja, hogy mi változot (egy változáslistát vezet az STE).

Ha ez nem lenne, akkor a következő lehetőségeink lennének:

• a kliens által módosított egész objektumot újra beleírni az adatbázisba (mondjuk ez nem értem miért rossz megoldás annyira, de mindegy :D - azért, mert így akkor is írsz az adatbázisba, ha nem módosult az objektum)
• lekérni az objektum jelenlegi állapotát a DBből, majd összehasonlítani a kliens által módosítottal és a változásokat visszaírni (plusz egy lekérdezés)

7. Milyen problémára és hogyan adnak választ a POCO és a POCO proxy osztályok az Entity Frameworkben? (4p.)

• Diák alapján*: Többrétegű alkalmazások esetén az állapotkövetést nem bízhatjuk az ObjectContextre, ezért nem használhatjuk az alapértelmezett EntityObject-et.

A POCO entitások változáskövetése nem automatikus és nincs lazy loading sem, csatoláskor az ObjectContext lekérdezi és tárolja tulajdonságainak értékeit. A DetectChanges metódus veti össze az az entitások eredeti és aktuális propertyjeit (és veszi fel az új entitásokat).

A POCO Proxy entitások támogatják az automatikus változáskövetést és lazy loadingot, azonban ehhez az entitásoknak szigurú követelményeknek kell megfelelniük.

• Általános:
  • Publikus, nem absztrakt és nem sealed osztály
  • Public/protected paraméter nélküli konstruktor
  • Nem implementálhatja az IEntityWithChangeTracker és az IEntityWithRelationships interfészeket
• Késleltetett betöltéshez:
  • Érintett tulajdonság (get): public, virtual, non sealed
• Változáskövetéshez:
  • Érintett tulajdonság (get, set): public, virtual, non sealed
  • Relációknál a * oldalat ICollection<T> reprezentálja
  • OC CreateObject függvényét használjuk new helyett

• Másképp*: POCO (Plain Old CLR Object) azért jó, mert a már meglévő osztályt tudod használni. Az elég nagy undorító dolog lehet, hogy minden osztályod az EntityObject-ből származik le és ez megkötheti a kezed az öröklés során meg csak úgy általánosan agyfaszt kapsz tőle. Erre megoldás a POCO osztály, aminek te

örülhetsz, hogy az EF ilyet is tud.

POCO proxy: futásidőben dinamikusan jönnek létre a proxy osztályok, amiknek a szülői az eredeti osztályok, de a propertyk overrideolva vannak, így minden lekérdezést elkapnak, amit el kell és akkor pl. a Navigation propertyre hivatkozáskor be tudják tölteni azt Lazy Loading.

Így a kecske is jól lakik (POCO osztályokat látunk továbbra is, csak igazából egy gyereküket használjuk), meg a káposzta is megmarad (működik pár funkció, amivel eddig kézzel kellett volna szopni: lazy loading, változás követés).

Felelősség

Természetesen nem vállalunk : )

AUT 2. mérés RÉGI (Linq + WPF)

Hasznos linkek

Informatikai technológiák laboratórium 1. AUT-os tárgyoldala:

http://www.aut.bme.hu/Portal/Targy.aspx?courseId=3d7b71f0-ca1b-48f4-adfd-cffeb4e26031

Adatvezérelt alkalmazások fejlesztése tárgyoldal

http://www.aut.bme.hu/Portal/aaf

1. Mi a különbség a Visual és Logical Tree között?

• Logical Tree*: A felépített ablak vezérlőinek hierarchiája
• Visual Tree*: Csomópontok helyett elemei megjelenítő objektumok vannak (pl ListBox -> Scrollbar, Border)

2. Mit nevezünk stílusnak?

Olyan objektum amelyben meghatározható, hogy egy adott célvezérlő melyik property-jeit milyen értékre állítsa át. Egységesítésre használjuk.

3. Milyen módon alkalmazhatunk stílusokat?

Logikai erőforrásként definináljuk őket, majd a kívánt vezérlőben a Style propertyvel hivatkozunk rájuk.

4. Mire valók a Control Templatek?

A Control Visual Treejét lehet megváltoztatni.

5. Mi a különbség a bináris és a logikai erőforrások között?

• Bináris erőforrás*: A hagyományos értelemben vett erőforrás (pl. kép, hang)
• Logikai erőforrás*: Példányosított objektumok (pl: Style, ControlTemplate), amelyek globálisan elérhetőek.

6. Mit nevezünk adatkötésnek?

Kér property összekötése. (forrás- és célobjektum) Függés alakul ki köztük. A célobjektum megadot properyje a forrásobjektum megadott propertyjének értékét fogja felvenni. DependencyProperty-k esetén változáskövetés is van.

7. Milyen módokon hivatkozhatunk a forrásobjektumra adatkötésben? (XAML)

<TextBlock Text="{Binding ElementName=treeView,Path=SelectedItem.Header}"/>

-- Velias - 2009.02.22.
-- FlamichTamas - 2009.04.19.
-- keeroy - 2010.05.10.