When Entity Framework was first released it was considered to be part of the core .NET Framework. But since then Microsoft realized that EF wasn’t a complete product and needed to augment it with “out-of-band” releases. This created a split between the core classes in System.Data.Entity.dll and the out-of-band classes in EntityFramework.dll.
Since then Microsoft decided to move Entity Framework entirely into an open source model. This requires further reorganization, but with the added problem that the core files can’t simply disappear out of .NET 4.0. To address this, Microsoft is using a namespace switch. “The general rule for namespace changes is that any type in System.Data.* is moved to System.Data.Entity.Core.*.”
There are a few exceptions:
- System.Data.EntityState => System.Data.Entity.EntityState
- System.Data.Objects.DataClasses.EdmFunctionAttribute =>System.Data.Entity.DbFunctionAttribute (Note that the class has been renamed; a class with the old name still exists and works, but it now marked as obsolete.)
- System.Data.Objects.EntityFunctions => System.Data.Entity.DbFunctions (Note that the class has been renamed; a class with the old name still exists and works, but it now marked as obsolete.)
- Spatial classes (e.g. DbGeography, DbGeometry) have moved from System.Data.Spatial => System.Data.Entity.Spatial
Project member ajcvickers goes on to explain that EF-related classes in the System.Data namespace that are in System.Data.dll will not be changed.
Before you update the using statements in your project you’ll want to remove any references to System.Data.Entity.dll. Otherwise you could end up mixing old and new versions of Entity Framework.
It should also be noted that third-party providers for Entity Framework 5 are not be compatible with EF 6. So if you are not using SQL Server or SQL Server Compact Edition then you’ll need to have your providers updated. The changes appear to be rather minor, just basic stuff like overriding IsGeographyColumn and GetGeographyAsync.
/filters:no_upscale()/sponsorship/topic/25afca57-6bcb-4c42-9a70-fbea10ce4fc7/MicrosoftLogoRSB-1678874949003.png)
/articles/debugging-beneath-trusted-abstraction/en/smallimage/debugging-outside-comfort-zone-diving-beneath-trusted-abstraction-small-1685961994992.jpg)
/articles/delivering-fast-testing-strategies/en/smallimage/deliver-fast-tests-have-to-last-small-1685548178496.jpg)
/articles/eda-mediator/en/smallimage/event-driven-architecture-with-mediator-topology-small-1685547200315.jpg)
/articles/azure-functions-quarkus/en/smallimage/azure-functions-on-quarkus-3-1685542580748.jpg)
/minibooks/architecture-2023/en/smallimage/logo-1685600892155.jpg){kind=logo}
/presentations/lyft-cd-benefits-challenges/en/smallimage/tom-wanielista-small-1685002834068.jpg)
/presentations/green-software-growth/en/smallimage/Marco-Valtas-small-1685609473905.jpg)
/articles/test-automation-ci-cd/en/smallimage/effective-test-automation-approaches-for-modern-CI-CD-pipelines-small-1685355310638.jpg)
/articles/impact-machine-learning-climate/en/smallimage/minimising-the-impact-of-machine-learning-on-our-climate-small-1685091723283.jpg)
/articles/kafka-clusters-cloudflare/en/smallimage/tales-of-Kafka-at-Cloudflare-small-1684768928637.jpg)
/presentations/refactoring-cleaning-code/en/smallimage/kent-beck-small-1684908700538.jpg)
Community comments
EF
by Ror Pop,
Re: EF
by Jonathan Allen,
Re: EF
by Ror Pop,
Re: EF
by Jonathan Allen,
Re: EF
by Julie Lerman,
Re: Julie Lerman
by Charles Cherry,
Re: EF
by Charlie Gillis,
Re: EF
by brian meahan,
Re: EF
by Matt Honeycutt,
Re: EF
by Jonathan Allen,
Re: EF
by Mike Henry,
Re: EF
by brian meahan,
EF
by Ror Pop,
Your message is awaiting moderation. Thank you for participating in the discussion.
EF is bloated, slow and unnecessary.
Use BLToolkit for ORM or Dapper for more flexible querying.
Re: EF
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
As a reporter I can't say that. I have to be as unbiased as possible unless I'm writing a product review that demands an opinion.
As a developer I think ORMs are a disgrace to the field of software engineering and the so-called "micro ORMs" are just a way to trick the fan boys into doing what the rest of us have been doing for years.
Re: EF
by Ror Pop,
Your message is awaiting moderation. Thank you for participating in the discussion.
ORM is a tool, an abstraction.
It's no more "disgraceful" than say C is in the presence of Assembly (which is itself an abstraction over binary machine code).
It could cause problems though, as any other tool, when people lack the understanding of its operations behind the scenes, and its cost in terms of performance and consistency guarantees.
Re: EF
by Julie Lerman,
Your message is awaiting moderation. Thank you for participating in the discussion.
seriously irresponsible comment considering you authored this article.
Re: Julie Lerman
by Charles Cherry,
Your message is awaiting moderation. Thank you for participating in the discussion.
+1 your comment about the author's comment
Re: EF
by Matt Honeycutt,
Your message is awaiting moderation. Thank you for participating in the discussion.
Well, everyone is entitled to their opinion, but that's a pretty naive one. As someone who built apps long before C# existed and dealt with the pain of doing things "by hand," even in the early .NET days, I would never consider going back to pre-ORM. ORMs are a very useful tool that address many of the impedance mismatch problems. That said, they are far from perfect, and there are many other tools out there that address some of the same pain points as ORMs. None of them are perfect. Not ORMs, not micro-ORMs, nor hand-rolled DALs, nor "light-weight" mapping or dynamics. NoSQL solutions aren't perfect, either. Each solution has pros and cons.
Re: EF
by Charlie Gillis,
Your message is awaiting moderation. Thank you for participating in the discussion.
+1 to Julie.
Re: EF
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
ORMs are designed to incredibly inefficient with the way they process data. If you want to avoid performing expensive SELECT * queries across tables you have to reintroduce the very same "impendence mistmatch" problems ORMs supposedly solve. By and large, using an ORM "correctly" requires as much or more code than just doing the mappings manually.
ORMs also violate the concept of encapsulation. Rather than creating a strongly defined API behind which you can alter table structures, ORMs are designed to directly bind to the tables. We have decades of database design theory that say you shouldn't do that. And on many occasions I have counseled companies that violated that rule and then discovered they were locked into their old designs.
ORMs shift a lot of work to the wrong side of the wire. While some people do go overboard, when used correctly stored procedures drastically reduce the amount of network traffic needed for data manipulation operations. And if the operations are transactional, the network latency is added to the amount of time you are holding onto those locks.
Finally, ORMs encourage bad table design practices. They don't work right unless you have one-to-one mappings between tables and classes. That means you either have lots of unnecessary objects on the client or lots of denormmalized tables on the server. Again, you can work around the one-to-one mapping issues, but it takes so much work that I don't see anyone honestly recommending it.
As far as I'm concerned, the only thing ORMs get right is the ability to send single-row updates in a way that only the rows that were actually changed go over the wire. Trying to do that using a stored procedure is usually far more pain that its worth. (But again, if the underlying table structure changes that single-row update becomes something the ORM can't easily handle.)
Re: EF
by Jonathan Allen,
Your message is awaiting moderation. Thank you for participating in the discussion.
C produces machine code that is far better than even most experts can write in assembly. When ORMs start producing SQL that is better than the typical junior developer can write, then I may change my stance.
Re: EF
by Mike Henry,
Your message is awaiting moderation. Thank you for participating in the discussion.
My comments will be from the perspective of using NHibernate (NH). But no, to use it properly requires a lot of time to understand how, not code. A one-time investment. Especially true if you use mappers like FluentNHibernate and conventions. You cannot possibly touch how little code I end up with using non-ORM approaches, when the technique is understood properly.
I may not understand exactly the rub here, but one can bind to views instead which certainly provides a level of encapsulation. Stored procs can also be used but not without neutering a lot of the capabilities of the [good] ORM.
I do. :) I couldn't disagree more with this statement. Again, coming from the NH world. In fact, it is why I only use NH because there isn't a single domain modeling nor database-entity diagram concern I was not able to use NH against in a very natural way. Value objects? No problem. Aggregate entities? Bring it. Table or class inheritance? NH gives you four different ways you can model this depending on your scenario (which is every one possible). Encrypted data? Great, create a one-time user datatype that draws in encrypt and decrpyt routines to handle it on a field level.
This is where a good ORM actually shines, in its ability to transform a database entity into a completely different object graph in code and vice-versa. For the record, I do not like EF whatsoever and will never use it thus I do not think it is a good ORM (tho worlds better in v6 than where it started).
Anyway, not likely to sway the author's opinion but his comments definitely deserved a retort.
Re: EF
by brian meahan,
Your message is awaiting moderation. Thank you for participating in the discussion.
+1
Re: EF
by brian meahan,
Your message is awaiting moderation. Thank you for participating in the discussion.
Well you've failed miserably on the unbiased part of being a "reporter"