I've been rolling my own object mapping system for over ten years and my current .NET version is pretty stable and I understand it. I've always kept a watchful eye on commercial developments in this area such a Hibernate but I've stuck with what I know.
However, I keep hearing more about Entity Framework and wondered whether it's time to investigate with a view to replacing my own home-grown system with Entity Framework. Microsoft has had a bit of a checkered history in this field with ObjectSpaces getting cancelled. I assume that project has become Entity Framework. Why did they cancel ObjectSpaces and have they got around the problems in Entity Framework? Is Entity Framework "better" than Hibernate?
Cheers, Rob.
I saw a demo of the entity framework ver 4.0 that will be released with Visual Studio 2010. Looked like it would make you very productive. I think this version will make it main stream for .net developers. More info here.
NHibernate has been around a lot longer and i think that if any .NET mapping library has reached critical mass, nHibernate would be it. Have you checked it out?
P.S. NHibernate is also a port from Hibernate which is THE mapping library for Java. That's a petty good pedigree.
Related
We are considering moving from Entity Framework to PLINQO L2S. EF has proven to be quite difficult for us to manage in an MVC3 application. I would agree there are areas of our application that can be improved, but overall, EF may not have been the best choice for us.
I am curious to know, recently, if anyone has moved form EF to PLINQO L2S? I have read many posts from back in 2010, but EF was a much different animal then. i am not interested in PLINQO for EF.
We ended up evaluating PLINQO and found there were bugs trying to emulate our model generated by Entity Framework. It was not an issue with how EF generated the database, but rather an issue with PLINQO appending numbers to collection entities. There was too much clean up for us to consider using PLINQO. It has some great features, but the generation caused us issues
We removed our DTO layer and decided to go with pure entities. The performance increase was huge. We tried several mapping libraries and even created our own direct mapping solution, but the cost in performance was too great.
I know Mono has no EF implementation, and no plans to create one.
Would it be possible, however, to simply take the relevant DLLs from .NET and add them into my Mono project in MonoDevelop? I may be completely misunderstanding how this is supposed to work; but wondered if this would then allow me to continue using EF + Mono rather than replacing the ORM.
Thanks.
For the Entity Framework on Mono status, see the mailing list post.
For the legal status, see Entity Framework license agreement. You are licensed to run Microsoft .Net on any legal copy of Windows, not on other operating systems. So even if this was technically possible, it would not solve your business problem. If you think now "what about ASP.NET MVC?" or something like that - those products are released by a different team and come with another license agreement that is much less restricted.
Since version 2.11.3 mono includes entity framework functionality.
I have been developing an inherited a product for the past couple of months that employs Microsoft Entity framework using the persistence ignorant POCO approach. I use a T4 templates to generate my POCOs which include Fixup methods.
My problem is that is just keep running into too many problems that I believe are inherent flaws in the design of Entity Framework. When I fix one thing another issue pops up.
My question is from a truly professional point of view where teams are writing medium to large scale revenue generating applications for desktop and web what are peoples experience and do people actually use Entity Framework in the "real world".
I realize this is a bit of an open question however I would like to survey peoples view to determine if I am fundamentally missing some core concept of EF.
Which version of EF? I'm using 4.1 and it's working just fine. You don't mention exactly what you're running into, but If you list specific issues, perhaps we (collectively) can help.
EDIT: Guys, sure I meant Entity Framework not ASP.NET MVC, it was a typo most probably!
Yesterday I came a cross this article that lists some of the bad stuff with Entity Framework. And after doing some google stuff I found this one which basically is the defender here. These two posts discussed some major issues of entity framework such as:
EF is not a failure because it doesn’t fit TDD development
EF is not a failure because business logic goes into partial classes
EF is not a failure because it treats data as an important part of biz objects
EF is not a failure because it accepts that most people do data first development
EF is not a failure because lazy loading is hard – lazy loading can destroy performance
EF is not a failure because its design tools are 1.0 level
EF is not a failure because it has a poor strategy for merging into source control
Now the points that really concern me in the above list are TDD fitness, Lazy Loading leak, and Source Control issues.
And here are my questions:
Can't I unit test my application methods good enough if I used EF?
What does it mean Lazy loading is hard? Is it unsupported at all by EF?
What does it mean that EF does have a poor strategy for merging into source control? aren't all the files gets checked-in and out like any normal file in the solution?
Hope this clears what I'm trying to ask here, and thank you guys for your assistance! Appreciate it!
Thanks for removing the typo from the question. Now I can make my answer a bit shorter too :-)
The Entity framework did not really offer support for the style of programming preferred by the TDD / SOLID / Alt.Net crowd. This is what the vote of no confidence is about. EF forces you to design your business logic around the persistence framework making it harder to test and maintain your business logic. On the positive side because of all the tooling around entity framework it allows you to get an object model and persistence layer up and running very quickly.
In newer version of EF this has gotten better. I don't know if EF 4 allows for persistance ignorant object models yet, this was the most important shortcoming. But in my opinion this does not really change the fact that EF was built for a different style of programming than the what the writers of the vote of no confidence want. EF leans heavily on tooling and steers you in a database centric way of building your software. The default way of building software is still create a database and generate your object model from that.
I don't think most of the issues surrounding EF are about what's possible. You can always abstract away the EF part from your business logic and build your application test driven. The issues are about what style of programming is made easier. I think you should use the right tool for the right job. If you're building enterprise software in a team that's comfortable with a data-driven style of development you should use EF. If you're building software where persistence is less important than business logic and you're working in a team that's familliar with TDD DDD, BDD, SOLID and all that stuff you're better off using something like nHibernate.
Developers had many grievances with Entity Framework 1.0 (.NET 3.5 SP1). The current release for EF 4.0 (Version 2 but so called because it's released as part of .NET 4.0) addresses most of these complaints. You can already download EF 4 Beta 1 if you are MSDN subscriber.
The Entity Framework Design team and the ADO.NET Team blog have a recent series of posts which talk about the various scenarios supports in EF 4.0 the biggest of which are Persistence Ignorance and POCO support, N-Tier support, T4 templates to name a few. TDD and Data/Model/Entities First are also supported by way of the aforementioned changes. Lazy loading is also there.
Regarding EF things are about to change to THE BETTER! :) EF4 is just around the corner and even though some voices still complain I don't see why they bother. EF has finally become maybe not mature it's only been in the works for a couple of years but at least a reliable and flexible framework.
So far I did not like EF. Although I liked the tools and how easy it was to create certain types of mappings and relations, Other types were a pain and the Linq support in EF wasn't so great (couln't create my own filter extension methods).
Is the new EF in .Net 4.0 better. Given what I have stated so far is there a chance I will like it.
The reson I ask this is because I use linq2sql a lot and do not like the feeling that the platform I am using is about to go obsolete. I would like to upgrade to something that is as similar as possible to what I already have.
Thanks for your opinions
It's only an opinion, but I believe that the new EF will be much improved. They will almost certainly have some kind of migration path from Linq to SQL. Whether it will look like Linq to SQL is another story. The two tools have somewhat different philosophies.
While EF will be designed for enterprise scenarios, it is my hope that the next version will still be lightweight enough to serve as an adequate replacement for L2S in small application scenarios.
I am really optimistic about EF 4.0 from all that I have seen thus far. The beta release is already available to MSDN subscribers and it addresses a lot of the concerns around POCO, Persistence Ignorance, N-Tier support and all that. I continue to recommend reading the ADO.NET team blog as a great resource for what's changed.
You can't compare it to the first release because this is a very big overhaul and a lot has changed.
That said, initial adopters always get the worst of it because they are the first to run into bugs and new problems while the late comes can benefit from the lessons learnt by the early adopters.
There has been a lot of improvements. I have ran in to a couple of strange issues but nothing unsolvable yet. It took me a few hours to understand how POCO works meaning they spent a lot of. I recommend you download VS2010 and play around with it yourself!
Have a look at this presentation, and you will know why EF worth your time.
How to Think Like the Entity Framework Presentation: http://blogs.teamb.com/craigstuntz/2009/09/11/38394/