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.
Related
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.
When Linq-to-Sql was first released, I used it quite a lot for small and medium sized projects where a true multi-tier architecture wasn't required.
NHibernate, Small Middleware, Overkill
Where I work, we now almost exclusively use NHibernate for true Domain Driven development.
I'm working on a small temporary (a lifetime of probably a year, maybe less) middleware component where NHibernate feels slightly overkill in terms of configuration and keeping the entities up to date. Especially because I haven't got any control over the DB, it sometimes changes, and it's a little bit "legacy".
Some changes were recently made to the DB, and the NHibernate mappings are not very complete.
Linq-to-Sql? Or EF?
I thought it might be easier just to rip out the IRepository implementation I have and replace it with a Linq-to-Sql implementation. Then I can just use lambdas for my simple queries, and just drag and drop the tables in.
RAD But Dead?
In this scenario the RAD elements of Linq-to-Sql make sense. But it's essentially old technology. Should I not use it? I've never used the Entity Framework. Should I use that, is it as easy and quick to use?
cheers
Is it still OK to use Linq-to-sql?
Yes. It is OK to use any technology which allows you delivering the product in time, with required functionality and quality. You can still find projects using ASP, ADO, VB6. One reason why Microsoft technologies have very hard time in many international corporations is that their products have very short lifetime. Linq-to-sql was on the market less then 2 years and was deprecated by Microsoft but companies / community argued about that and Microsoft changed their strategy little bit. Linq-to-sql doesn't have new features but it is still supported and a fully functional technology.
Will Linq-to-sql or EF solve your problems?
It depends. Perhaps yes and perhaps no. Don't believe to marketing announcements about RAD. Sometimes I feel that people think that RAD is about designer. No. Tools supporting RAD are about well defined API which is easy to understand, easy to use and doesn't contain unexpected behavior (Principle of least surprise) - you will use the API to quickly prototype the application but it still requires understanding and practice. NHibernate's mapping is still prototyping when you compare it with manually doing whole data access. We can even follow the basic rule of good framework: Easy things are easy to do and hard things are possible. That is something that NHibernate accomplish much better then EF or Linq-to-sql.
If you know NHibernate but you don't have any real world experience with EF or Linq-to-sql, you can be sure that neither Linq-to-sql or EF will increase your productivity in first one or two projects where you use it. If you don't have too much experience with NHibernate changing to EF or Linq-to-sql will probably don't cause temporary lose of productivity.
I also don't think that EF or Linq-to-sql will generally help you in situations where database changes. As I remember Linq-to-sql designer doesn't have update mapping functionality at all and because of that it is very often used completely without designer so you must still manually modify mapping. EF's updating model from database can be helpful here but it is not a silver bullet. Some updates can require manual modification of EDMX file (huge XML).
At last be aware that NHibernate's mapping features are much more powerful especially when working with legacy databases. Linq-to-sql's mapping features are very limited, it is mostly 1:1 mapping of tables to classes with some exceptions (basic TPH inheritance). EF offers more complex mapping features but it somehow expects a correct design of the database.
If you (and your coworkers) are comfortable with NHibernate, then it should be just as RAD as Linq to SQL. There's no reason not to use L2S as long as you understand it's not going to get much in the way of updates and improvements from Microsoft, but in my experience if you know how to use both frameworks already, no need in re-doing the work just because L2S might be a little more RAD
Some good discussion on NHibernate vs L2S/EF
Entity Framework vs LINQ to SQL
MS Entity Framework VS NHibernate and its derived contribs (FluentNHibernate, Linq for NHibernate)
in your specific case, you should go with technology you are most comfortable with. Though Linq2Sql is relatively straight forward - and build right into the language - it does have a slight learning curve and its own set of gotchas!
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.