Talk:Entity Framework

"The disadvantage of this approach is that if this schema is changed the application is not shielded from the change."

This is not the disadvantage of tying app code to db schema, this is a myth. DB schemas should NOT change in ways that break apps. And if/when they do (such as during development), it's probably because the app is required to change accordingly, so being "shielded" from the change is besides the point.

The greatest disadvantage of code being tied directly to the db schema model is cognitive: db physical schemas rarely represent the domain model well, yet the latter is what we'd like to work with in OO code.

"It is geared towards solving the mismatch between the formats in which data is stored in a database and in which it is consumed in an object-oriented programming language or other front ends."

I think "formats" is the wrong word. It goes beyond what most people think of as formatting. Better would be something like "architecture", or "organizational structure", etc.

Larry Leonard (talk) 22:42, 8 April 2008 (UTC)

Schema? --soum ^talk 04:07, 9 April 2008 (UTC)

I just got back from TechEd and was talking about this with the guys from MS. Everyone things their product is doing something new or different so they don't want to fully categorize it as ORM or something else. But this is exactly what the Entity Framework is. Just because they make their other services aware of EF doesn't make it different from any other ORM framework. I.E. you can use Jasper reports in Java against Hibernate.

Anyway I would like the opening paragraph to more clearly define EF, again not marketing jargon but based on what it is, not just it's vision. --Kibbled bits (talk) 03:16, 13 July 2008 (UTC)

Much of this text is very close to MS' own documentation on the feature and doesn't question their assertions of superiority over the standard means of doing this - a well-designed application will be shielded from change to the logical data model by views and stored procedures in any case, which this does not at all mention. Eftpotrm (talk) 17:14, 19 February 2009 (UTC)

I am not the most advanced programmer out there, but I choose to use Microsoft Access, Visual Basic scripting, ASP, and ADO on a regular basis and am attempting to learn ASP.NET and ADO.NET. I cannot make any sense out this article. It is just chock full of jargon that I cannot follow. For reference, I cannot follow most of Microsoft's documentation either, instead relying on other people's interpretations and simplifications. —Preceding unsigned comment added by 128.230.9.250 (talk) 13:41, 26 May 2009 (UTC)

Claiming that EF is "far superior than NHibernate," which, by the way should read "far superior to NHibernate," is just obscene. Not only is there no proof, I'm not even sure there is a way to prove such an assumption. Flag time? —Preceding unsigned comment added by 24.185.44.164 (talk) 19:46, 13 June 2009 (UTC)

"It differs from SQL in that it does not have explicit constructs for joins because the EDM is designed to abstract partitioning data across tables"

Huh? http://msdn.microsoft.com/en-us/library/bb387167.aspx Would seem to imply otherwise... and frankly if you could not join tables that are not explicity related by some foreign key (but there's an implicit relationship, say zipcodes) through linq to entities or Enities SQL, you'd probably use a different ORM. 71.154.18.245 (talk) 14:12, 7 August 2009 (UTC)

"The second version of Entity Framework [...] is available in Beta form as part of Visual Studio 2010,..."

Correct me if I'm wrong but I've found no evidence that Visual Studio 2010 is shipped with a beta-version of EF. I'm guessing that is refers to the release candidate of VS2010.