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.
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.
EF 4.1 CodeFirst looks great. It works and sells wonderfuly with basic examples that have one or two joins, but what about larger applications? Did anybody work on a large application where domain and data access layers were implemented with EF 4.1 code first? Did it work? Was it as easy and smooth as examples on asp.net site? I'm mainly working on MVC applications, where there is no change tracking. So far I have been using LINQ-to-SQL, which worked well with some extra mapping code.
Thank you
I'm in the later stages of developing a web application that is fairly complex with EF 4.1 CodeFirst (well its more complex than most examples). I don't pretend to be an expert on code first so others may have different opinions.
I used a domain driven approach along with the repository pattern. The database created by code first worked well though I had to manually optimize the database and add indexes etc. Did have an issue bolting on mvc-profiler but nothing drastic.
There was a learning curve but I reckon that was more down to my lack of knowledge about code-first than anything intrinsically difficult about it. When we started developing the app the ability to recreate a db and seed it sped things up at the start. Though we have disabled that now and any db changes are made manually and the code is updated.
So for me code first worked well, I like this approach for new applications and it wasnt too difficult to get up and running (lots of reading up).
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/
We been having some discussions on approaches to using the entity framework at work recently. We have a fairly large and complex n-tier web based application, which is due for a major overhaul.
The question is: If we where to starting using the entity framework, would it be better to create one big model, or a set of smaller functional/acivity based models.
I have my own opinions on this, but would be interested to hear what some other people think.
Update (17th November 2008):
I have been creating one model, wiping it out and re-creating, etc for small projects at home. Although I haven't tried, I suspect that this approach will be a bit more challenging when there are a large number of entity types involved.
Also, does anyone have any experience of using ef with a large team using TFS or similar?
In my experience with it, I would just make one big model of the database. Otherwise, it might be hard to track what tables changed where. When I make changes to the database, I just delete all the tables in the model and regenerate it.
Of course, I also didn't customize my model by adding "entity" functionality to it (not sure how that works exactly).
So I'm no expert in it, but I usually end up using the LINQ-To-SQL models/objects instead of the Entity Framework - it's worked better for me so far.