Jag antar att ni redan sett
http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/ ?

Mycket av kritiken är relevant (ingen lazy load och dåligt stöd för source control är synnerligen kasst), men stycket om "SHARED, CANONICAL MODEL CONTRADICTS SOFTWARE BEST PRACTICES" är vagt. Är det någon här som vet vad det är för konkreta features i EF som kritiseras, eller som man anser saknas?

mvh,

/Anders Ivner

Jag skummade igenom den lite snabbt för någon dag sedan och har inte direkt någon erfarenhet av EF då jag kört NHibernate och fått känslan av att de flesta inte tycker om den som den är i nuläget, den är ju t.ex. inte POCO just nu. POCO skall den tydligen bli i version 2 läste jag i något forum dock ingen säker källa.

Jag tycker att kritiken är överdriven.

Det är många som bara hakar på kritiken som mindless drones för att de läst att POCO och lazy load is the shit.

POCO är förvisso trevligt eftersom det gör att man får väldigt lite kod och den blir tydlig.
Men jag måste säga att jag skiter rätt hårt i om en property är av typen "Order" eller "EntityRef<Order>"

Det är marginellt mer kod och det är fortfarande jättetydligt vad som menas..

På ett sätt kan det tom. vara tydligare eftersom man faktiskt ser att det är ett speciellt beteende associerat med just den propertyn.

Så POCO eller inte, så länge det är en _liten men tydlig_ kodbas jag har så är jag nöjd.
Nu har jag inte kollat hur entiteterna blir i EF, de kanske blir jättebloatade, det jag menar är bara att POCO är inte det man strävar efter, det är _effekterna_ av POCO man vill åt: liten kod och tydlig kod.. vilket går att åstadkomma även på andra sätt..
(Och om någon vill dra det klassiska POCO argumentet om att man kan helt lätt bara byta mapper om man har POCO så tar jag gärna den diskussionen också ;) )

Lazy Load en feature som många tycker är jättehäftig.

Lazy load har dock massa sidoeffekter som många inte känner till.
Det faktum att all data i din graf inte laddas samtidigt / i en transaktion gör att du kan få inkonsistens i din data.

T.ex., du laddar en order med det ackumulerade fältet "OrderTotal" , 3 minuter senare så lazyloadar du "order.OrderDetails" som har hunnit förändras i din databas från det att du laddade din order...
Då stämmer inte den ackumulerade summan med den beräknade summan i din order.
Den typen av fel kan ge väldigt märkliga buggar som är svåra att hitta.. och de är helt onödiga..
(Och jag vet att det var ett jättedåligt exempel, ville bara ge en hint om varför det blir fel)

Och om vi ska prata tydlighet i kodbasen så är lazyload direkt dåligt.
Det är fullständigt omöjligt att se om en kodsnutt kommer använda redan laddad data eller om den kommer trigga en lazy load.

Om det vore så att lazy load vore 100% sidoeffektfri (som lazy eval i functional programming) så vore det inga problem , men lazy load ger prestanda hits (jämfört med att accessa en redan laddad property) och ger inkonsistens i din data..

Du kan omöjligt veta om en beräkning på en lazyladdad property kommer resultera i det svar som du förväntar dig eller hur många roundtrips till din datakälla en kodsnutt kommer resultera i..

Det man behöver är "load spans", så att man i förväg kan speca per query vilka properties i en hel graf som jag är intresserad av i ett visst usecase.

Då slipper man de dåliga effekterna av lazy load och de dåliga effekterna av full eager load(dvs dra upp nästan hela databasen)


Det är iaf mina slutsatser efter att utvecklat NPersist som har både POCO och full lazy load support sedan 2005 :-)

//Roger

Jag håller med dig om det mesta du skriver. Dock måste jag säga att jag tycker att lazy load har sin befogade plats och att kritiken mot EF på denna punkt har ett visst fog.

Inkonsistensproblemet är naturligtvis något som man måste vara medveten om, men det skulle man vara tvungen att hantera oavsett lazy load. Man kan:
- (Om det är inom t.ex. ett serviceanrop) Köra allt i en transaktion med tillräcklig isolation.
- Göra en verksamhetsmässig bedömning av att man inte får några farliga konsekvenser (något man måste göra i vilket fall om man inte kör allt i isolation=serializeable).
- Använda optimistisk låsning. Det bör man göra ändå om man har långa transaktioner.

Jag håller med om att man bör försöka ladda data explicit - t.ex. med load spans - av prestandaskäl, men en sådan strategi ersätter inte helt behovet av lazy load. Definitionen av "spansen" introducerar redundans i koden och kan också bryta mot enkapsuleringen om man har komplex logik (dvs om A anropar B så bör ett span för A inkudera data som behövs av B).

Det är iaf min erfarenhet efter att ha utvecklat Bold/ECO som haft lazy load sedan 1996 ;-) (ursäkta, det gick inte att motstå :-)). Men däremot inget POCO.

/Anders

>>Dock måste jag säga att jag tycker att lazy load har sin befogade plats

De har ju Explicit lazy load eller vad man ska kalla den..
Det går att ladda en property i efterhand, men man måste göra det själv : ".Load()"

Jag tycker det är snyggare, då krävs det att utvecklaren vet vad han gör istället för att massa magi ska kicka igång bakom kulisserna.

Features som har sideeffects bör vara explicita.

>>post1: dåligt stöd för source control

Det där var NHibernate Oren / Ayende som drog upp.
Designer surface filen ger konflikter om flera gör ändringar på samma yta.
Och jag vetefaen om jag tycker det är ett sånnt jätteproblem.
Lite som att säga att photoshop ger konflikter om två personer ritar på samma bmp bild..

I hans fall så handlar det nog mer om prestige, att det känns illa att folk slutar köra NH.

>>Dock måste jag säga att jag tycker att lazy load har sin befogade plats
jag tycker implicit LazyLoad är av ondo. Om man inte vet vilken data man vill ha och när så man kan bygga ett loadspan så skall man fundera över sin design. Implicit Lazy Loading är en sista utväg och leder oftast till kod som hamrar databasen. Speciellt för utvecklare som inte kan ORM vilket är majoriteten av de som är målgruppen för EF. Därav den explicita .Load för att vara tydlig mot de som använder den när de rör databasen.

F-Ö tycker jag vote of no confidence är lite löjlig. MS har redan visat att är öppna för feedback runt EF, de har tagit flera steg i rätt riktning och visar att de lyssnar genom sitt initiativ med den öppna design processen (där alla features i V2 diskuteras).

V2 innefattar f-ö POCO stöd, implict lazy loading, bättre n-tier support med change graphs, möjlighet till code-first (dvs klasserna först databasen sen), bättre stöd för mockning och stubbning för TDD scenarion (och enhetstest i allmänhet).

Håller med att lazy loading kan skapa problem och kräver större ORM kunskap. Men transparent lazy loading underlättar väldigt mycket när man skriver enhetstester. Man får renare och mindre business kod och större seperation of concerns. Man få ta det onda med det goda, och i detta fall tycker jag de goda sidorna av Lazy loading överväger det dåliga :)

Tycker det mesta i brevet var välskrivet och befogat men håller med att "vote of no confidence" var ett löjligt namn.

Visst har dom varit öppna för feedback men dom verkar inte lyssnat på något av den:
Scott Bellware: "The authors of the letter, and a number of the signatories have been giving the team feedback since March of 2007. We've met three times in-person, and we've had a number of communications in text media."

Jag tror att de som skrev brevet är lite sura på Microsoft för att dom släpper en skarp version av en produkt som inte är färdigt och som kan göra mer skada en gott. Det vore kalas om dom hade valt samma utveklingsprocess som ASP.NET MVC med korta leveranser och öppen källkod och framför allt snabbt svar på feedback, och sen låta communityn bedömma när grunderna är klara och man kan släppa en v1 (detta lär ju vara en dröm dock, men kan ju inte tillfredställa alla)

Efter att ha lästs Tim Mallaliue's svar så ser det väldigt ljust ut för v2, dvs om dom lyssnar på personerna i deras "advisory council" :)