Na, ez aztán a furcsa. Pár napja írtam, mennyire lassan indul az EF. Nem tudom mitől, talán attól, hogy felraktam a Microsoft ADO.NET Entity Framework Feature Community Technology Preview 2-t, ami lecserélte a bugos .NET 4 Beta2-es EF assemblyket, amelyek nem használták ki az előfordított viewkat? Nem tudom, nem nyomoztam utána, mert most jó. :)
Korábban annyira felbosszantott, hogy elkezdtem nézni az NHibernate-et, de ahhoz meg a LINQ támogatás jár még gyerekcipőben, nekem meg tele van azzal a programom. Így az kiesett.
Marad az EF, így már nagyon szeretem.
Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.
LEAVE A COMMENT
13 COMMENTS
Hát, mi felokosítottuk a “fapados” Linq2Sql-t enterprisey szintre, és azzal toljuk. Nem kell a teljes ORM, v1-es cuccban pláne…
Gondoltam erre, de hosszú távon az kihal. Ezért inkább EF-et tanulok és használok.
Elég sokan kezdtek vele dolgozni, és az EF-ből tudomásom szerint még mindig hiányzik az SP támogatás, és sok vele a szívás. Remélem nem hal ki…
A v2 már jó lesz. Van SP támogatás is.
EF1-ben tapasztalataim szerint nem az előfordított viewk használata turbózta meg a dolgot, hanem az, hogy a MetaDataWorkSpace (mdws)létrehozása. Kimértem profilerrel. Megoldás az lett, hogy egyszer kiszenvedtettem a mdws kikalkulását, majd legközelebb mindig az EntityConnectionnek azt a konstruktorát használtam, ahol a mdws is megadhtaó.
EF4 esetében eddig nem szorultem ilyen megoldásra, mert az megy, mint disznó.
Designer helyett a Code Only megoldást használjuk:
http://blogs.msdn.com/efdesign/archive/2009/06/10/code-only.aspx
http://blogs.msdn.com/efdesign/archive/2009/08/03/code-only-enhancements.aspx
http://blogs.msdn.com/adonet/pages/feature-ctp-walkthrough-code-only-for-the-entity-framework.aspx
A Code Onlyhoz persze kell a Feature CTP 2.
Szigorúan POCO-kat használunk. Mert azért Persistence Ignorance kell, jól.
Kurva jó az EF4. Csak lehetne mán detached object graph-ot is perzisztálni. Szóval az n-tier támogatás még halvány, ott még trükközni kell.
Ezelőtt mi is saját megoldást pakoltunk Linq2SQL és EF1 fölé, hogy POCO-kba toljuk át az adatokat. De az EF4-nél már nem kell. Végre eljutott a Microsoft is oda, hogy csinál(t) egy normális ORM-et.
kpocza: ez a code only érdekes, meg is nézem, mivel úgyis én rakom össze mindkét oldalt, nem kell nagyon mapelni, így a konvenció alapú megoldás jó lehet.
Viszont eszembe jutott egy kérdés. Van egy jól normalizált adatbázis, A táblához kapcsolódik B,C, D tábla. Ezek id, value jellegű lookup táblák, egy-több kapcsolattal A felé. Pl. B id, szín értékeket tartalmaz, A-ban van egy-egy FK B, C, D-re.
Ezek értékeit szeretnem read-only módon beletolni A-ba, így nem kell állandóan a kapcsolatokon navigálnom. Mi ennek a legszakosabb módja? Amit eddig láttam (joinos), az nem tetszett.
Nem 1-1 kapcsolat van a táblák között azonos PK-val, úgy látom ez az, ami jobban meg van támogatva.
Ez mit is jelent? “Ezek értékeit szeretnem read-only módon beletolni A-ba, így nem kell állandóan a kapcsolatokon navigálnom”
A.B.Value helyett A.BValue valami listás megoldásnál???
joinos megoldás?
Ki tudnád fejteni részletesebben a dolgot?
Arra gondolok, hogy az A táblában van egy szám, pl. 8, ami a B táblában a piros színt jelenti. A-ban ki akarom cserélni a 8-at pirosra.
A joinos megoldás ez:
http://msmvps.com/blogs/matthieu/archive/2008/06/20/entity-framework-how-to-use-entity-splitting-with-different-pk.aspx
Aha.
Amikor EF1-ben ilyent csináltam, akkor egy View-t kapcsoltam (ahol a 8 helyett már piros volt) az entitáshoz. Illetve amikor a A.B.Value is kellett, de el akartam érni A.BValue-ként is, akkor csináltam egy BValue get property-t.
Nem nagyon szebb megoldások ezek sem, mint amit mondtál.
Én az utóbbit csináltam, de nem tetszik. Még a view a leghasználhatóbb talán. Köszi a tippeket.
Meg tudja nekem mondani valaki, hogy hogyan lehet EF segitsegevel mappelni egy olyan “User” entitast, akinek van egy userneve es egy passwordje, amit hashelve tarolunk a db-ben ugy, hogy a kiszamolt hash sose jojjon vissza a db-bol? (azaz a password csak set-es property legyen, es csak a db fele menjen, visszafele ne mappelodjon)
Néztem két irományt a Linq2Sql vs Entity Framework témában, itt írtam róla: http://www.grape.hu/hu/blog/gerleim/linq2sql-vs-entity-framework.aspx
EF kérdés. Tervezés során az entitásaim két kategóriába soroltam. Vannak elsőosztályú entitások (pl user, profile, organization, etc.) és vannak alárendelt entitások (pl. history, permission, notifysubscription, etc.)
Hogyan különítem el őket úgy, hogy az architektúra tükrözze ezt a kategorizálást?