„Informatikai technológiák laboratórium 1 - AUT 2. mérés: Entity Framework” változatai közötti eltérés
Ugrás a navigációhoz
Ugrás a kereséshez
(vitalap) (Új oldal, tartalma: „{{GlobalTemplate|Infoszak|InfTechLaborAUT2}} ==Hasznos Linkek:== Informatikai technológiák laboratórium 1. AUT-os tárgyoldala: http://www.aut.bme.hu/Portal/Targ…”) |
|||
| (3 közbenső módosítás, amit 2 másik szerkesztő végzett, nincs mutatva) | |||
| 1. sor: | 1. sor: | ||
| − | {{ | + | {{vissza|Informatikai technológiák laboratórium 1}} |
| − | |||
| − | |||
| − | |||
| + | ==Hasznos linkek== | ||
Informatikai technológiák laboratórium 1. AUT-os tárgyoldala: | Informatikai technológiák laboratórium 1. AUT-os tárgyoldala: | ||
| 13. sor: | 11. sor: | ||
==1. Sorold fel az Entity Framework három leképzési rétegét! (2p.) == | ==1. Sorold fel az Entity Framework három leképzési rétegét! (2p.) == | ||
| − | |||
* Conceptual Model | * Conceptual Model | ||
* Map | * Map | ||
| 24. sor: | 21. sor: | ||
==2. Milyen lehetőségek vannak Entity Frameworkben egy osztály adattáblákra való leképzésére? (2p.) == | ==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) | * Egy hierarchia egy táblába | Table per Hierarchy (TPH) | ||
* Minden típus saját táblába | Table per Type (TPT) | * 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) | * 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”, | + | ==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). | |
| − | 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 | Másik lehetőség az Eager loading, ami a kért navigációs propertykhez tartozó entitásokat is automatikusan | ||
| 39. sor: | 32. sor: | ||
==4. Az Entity Framework 3 alapvető módszert kínál az entitások elérésére. Melyek ezek? (2p.)== | ==4. Az Entity Framework 3 alapvető módszert kínál az entitások elérésére. Melyek ezek? (2p.)== | ||
| − | |||
* LINQ to Entities | * LINQ to Entities | ||
* Entity SQL with Entity Client | * Entity SQL with Entity Client | ||
| 45. sor: | 37. sor: | ||
==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.) == | ==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 | 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.)== | ==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. | *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. | *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. | + | 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). |
| − | Í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: | 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) | + | * 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) | * 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.)== | ==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. | |
| − | |||
| − | |||
| − | |||
| − | 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: | * Általános: | ||
| 83. sor: | 67. sor: | ||
** OC CreateObject függvényét használjuk new helyett | ** 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 | + | *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 |
| − | 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. | ö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 | + | 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. |
| − | 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 | + | Í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). |
| − | 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== | ==Felelősség== | ||
| − | |||
Természetesen nem vállalunk : ) | Természetesen nem vállalunk : ) | ||
=AUT 2. mérés RÉGI (Linq + WPF)= | =AUT 2. mérés RÉGI (Linq + WPF)= | ||
| − | ==Hasznos | + | ==Hasznos linkek== |
| − | |||
Informatikai technológiák laboratórium 1. AUT-os tárgyoldala: | Informatikai technológiák laboratórium 1. AUT-os tárgyoldala: | ||
| 113. sor: | 89. sor: | ||
==1. Mi a különbség a Visual és Logical Tree között?== | ==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 | *Logical Tree*: A felépített ablak vezérlőinek hierarchiája | ||
| − | *Visual Tree*: Csomópontok helyett elemei megjelenítő objektumok vannak (pl | + | *Visual Tree*: Csomópontok helyett elemei megjelenítő objektumok vannak (pl ListBox -> Scrollbar, Border) |
==2. Mit nevezünk stílusnak?== | ==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. | 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?== | ==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. | 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?== | ==4. Mire valók a Control Templatek?== | ||
| − | |||
A Control Visual Treejét lehet megváltoztatni. | 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?== | ==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) | *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. | *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?== | ==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. | 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. | ||
A lap jelenlegi, 2015. május 18., 11:35-kori változata
Tartalomjegyzék
- 1 Hasznos linkek
- 2 1. Sorold fel az Entity Framework három leképzési rétegét! (2p.)
- 3 2. Milyen lehetőségek vannak Entity Frameworkben egy osztály adattáblákra való leképzésére? (2p.)
- 4 3. Mit jelent a „lazy loading”, milyen szerepet kap az Entity Frameworkben? (2p.)
- 5 4. Az Entity Framework 3 alapvető módszert kínál az entitások elérésére. Melyek ezek? (2p.)
- 6 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.)
- 7 6. Milyen problémára és hogyan ad választ a „self-tracking entity” megoldás az Entity Frameworkben? (2p.)
- 8 7. Milyen problémára és hogyan adnak választ a POCO és a POCO proxy osztályok az Entity Frameworkben? (4p.)
- 9 Felelősség
- 10 AUT 2. mérés RÉGI (Linq + WPF)
- 10.1 Hasznos linkek
- 10.2 1. Mi a különbség a Visual és Logical Tree között?
- 10.3 2. Mit nevezünk stílusnak?
- 10.4 3. Milyen módon alkalmazhatunk stílusokat?
- 10.5 4. Mire valók a Control Templatek?
- 10.6 5. Mi a különbség a bináris és a logikai erőforrások között?
- 10.7 6. Mit nevezünk adatkötésnek?
- 10.8 7. Milyen módokon hivatkozhatunk a forrásobjektumra adatkötésben? (XAML)
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.
