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

2015-05-18T11:35:17Z

Czémán Arnold: /* 3. Mit jelent a „lazy loading”, melyen szerepet kap az Entity Frameworkben? (2p.) */

{{vissza|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}"/>

-- [[PallosTamas|Velias]] - 2009.02.22. <BR>
-- [[FlamichTamas]] - 2009.04.19. <BR>
-- [[ZsolnaiKaroly|keeroy]] - 2010.05.10. <BR>

[[Category:Infoszak]]

VIK Wiki - Felhasználó közreműködései [hu]

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