Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 8 down vote favorite
3

I'm a junior developer who's just completed a project using Entity framework. Unfortunately I was chewed out by one of the Senior Developers at my work citing that I should have used ADO.net and that Entity Framework quote: "Is not reliable or feasible in a corporate application".

Although I think this is mostly exaggeration - are there any truth to his claims? If so, what are the facts / sources (and will this change with the release of Entity Framework 5)? If not - what can I use to justify my position that Entity is as reliable as ADO.net.

share|improve this question
1  
Michael realise that it may be worthwile reading up on the repository pattern and unit of work. Once you start working with EF and the dbcontext and dbset you will see similarites. Note. Strictly speak DBContext and DBset is not an exact implementation of the above patterns but more of a slight variation. Btw, your senior dev would have suggested straight ADO as it gives you more control. – Eminem Aug 3 '12 at 6:12
1  
I would ask him to explain what does he meant by "Is not reliable or feasible in a corporate application". Make him give specific reasons. Apparently, he is talking over the articles he saw on the internet. – tugberk Aug 3 '12 at 8:21
1  
I dislike the "optimization" arguments against it. Most corporate applications don't receive enough traffic for this to outweigh speed of development. Some do but most do not...and even then you can pull those things out and do what you want to optimize it. – Rig Aug 3 '12 at 14:26
I closed this as not constructive because unfortunately without focusing on a specific advantage or disadvantage or concrete facts about ADO.NET and Entity Framework then this will start to devolve into a discussion about which technology is better. This is highly variable on a number of factors which are too broad and vast to make this question answerable. I do encourage you however to join the chat room for a discussion about Entity Framework vs. ADO.NET. – maple_shaft♦ Aug 3 '12 at 14:59

closed as not constructive by maple_shaft♦ Aug 3 '12 at 14:56

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

5 Answers

up vote 17 down vote accepted

There is a misconception that Entity Framework (EF) is very slow than ADO.NET and should not be considered for Enterprise level applications. Basically, it depends on how you use it.

The EF is helping to eliminate the impedance mismatch between data models and between languages that application developers would otherwise have to deal with. Two innovations that make this move possible are Language-Integrated Query (LINQ) and the ADO.NET Entity Framework. The Entity Framework exists as a new part of the ADO.NET family of technologies.

It provide a big boost in development productivity which is its strongest advocate.

Depending on your application needs performance of EF can be optimized. In addition, it also supports usage of stored procedure starting from EF4.

I have also made re-search on topic and find some good posts that also had positive impact on performance of EF.

Last but not least, according to recent news from EF team, there are numerious improvment in performance of EF4.3, howevet i personally did not play with it.

A good discussion to look for comparison - Entity Framework VS LINQ to SQL VS ADO.NET with stored procedures?

share|improve this answer
1  
Excellent - thank-you for the resources, I will check it out! – ElvisLikeBear Aug 3 '12 at 4:27
3  
+1 - we've got a EF 4.3 based DAL doing > 100 TPS, with mapped PROCs. The dev productivity benefits of especially queries with LINQ is enormous. – StuartC Aug 3 '12 at 5:22
1  
Yes EF (Entity Framework) has the nice bells and whistles. But beware when errors start to pop up. Unless you willing to download the recently open source EF and step through that code (as I had to recently do), you're in for a tough time debugging. (Try debugging without a tracing on sql server). However EF is a nice protected way of introducing you to mappings and its Code First or DB First approach is worthwhile learning especially for a someone new in the industry. For serious high performance benchmarking, I would avoid it. For run of the mill business apps it can work – Eminem Aug 3 '12 at 6:07
I'll chime in with @nonnb and mention that I was on a project that developed a system that processed 800K+ XML documents an hour using EF4. – TMN Aug 3 '12 at 14:10
up vote 8 down vote

Some .NET programmers are decidedly "old school" and conjure up reasons/excuses not to use LINQ, EF or other newer .NET methods. Some of it has to do with them having a "we've always done it this way" attitude or having bad experiences with bloated .NET DB object libraries in the past. I was this way for a while myself until, during a period of unemployment, I took the time to learn them and realized how helpful they were in building a well structured app and how much work they saved.

That said, there can be situations where using ADO.NET is preferable. For example, I recently had to write a console app that interacted with existing, complex, databases that had 100's of legacy SPs and odd table structures (no primary keys, etc). In this case, it was quicker and easier not to use EF rather than shoehorning it into a dirty legacy DB.

Remember, there's rarely a good reason to switch a existing app over to a new DB library that's working well (ie "if it ain't broke, don't fix it"). This can be a factor in some organizations. This wouldn't exclude its use by new apps although some might see an advantage in keeping the techniques used consistent.

Lastly, EF performs just fine for your average corporate CRUD type app running on desktops or an intranet site. It's done well for external internet sites where I've used it but these haven't been particularly high traffic ones.

share|improve this answer
1  
Even external high-traffic sites can scale up if you throw more hardware at it. On the whole though my experiences match yours with Entity Framework and LINQ. At first I was skeptical then I saw the light. – maple_shaft♦ Aug 3 '12 at 12:18
up vote 5 down vote

There's a good chance that your "Senior Developer" is a dinosaur who has not kept pace with any of the developments in the field in the last decade. There's a natural inclination for such people to insist (without any evidence) that the old technology (which they know inside-out) is superior to the new technology (which they're completely ignorant of).

Entity Framework is absolutely reliable and feasible for corporate applications, and there are countless successful corporate applications using it to demonstrate this fact. I've been involved in the development of a number of them myself. Yes it's possible for inexperienced users to come up with some code that looks clean and sweet but causes nasty performance problems (e.g. the infamous "N+1 Problem"), but I would argue that you need to know what you're doing with any tool. I'm sure we've all seen people leaking connections left right and centre with classic ADO.NET

Having said all that, your senior developer was actually well within his rights to chew you out if you arbitrarily made the decision to use an ORM or indeed any major component which was not currently in active use within your organization, without consultation. That's not the sort of decision a junior developer should be making without discussion. Of course if the decision was made with consultation and this guy was an uninvolved party who just jumped in and started bitching at the end of the project, feel free to not pay him too much heed unless and until he actually comes up with coherent arguments to support his claims.

share|improve this answer
1  
Unfortunately the spec I was given didn't specify what framework I should use and he did not reply to my e-mail about this until after the deadline had passed. I'm new to this role (having started just writing SQL for the past year) so I was unfamiliar with what has been done in other projects also. – ElvisLikeBear Aug 3 '12 at 13:38
@Michael - if he didn't bother to specify, and then didn't bother to respond to queries, then it's hard to be too sympathetic towards his complaints. – Carson63000 Aug 3 '12 at 23:33
up vote 4 down vote

The Entity Framework does have some problems, but they're not really in the reliability arena. The biggest issue is that it handicaps the ability to do a lot of optimization on the DB side due to the dynamic nature of the access. If you have a strong DB team, you'll be wasting that talent. Stored procs can be used to mitigate that, but if you're writing procs for all of your access, Entity Framework doesn't get you too much.

Entity framework also tends to fall down a bit when you go outside of its comfort zone. If you're mostly doing CRUD and maybe some straight-forward, quick running stored procedure calls, then it's fine. Enterprise apps tend to push that envelope.

share|improve this answer
That it doesn't take advantage of optimization is another misconception. There have been significant (borderline amazing) performance improvements in recent EF releases, including plan caching. In my experience, the performance difference between most EF-generated queries and stored procedures is so marginal that it hasn't been worth the time (a.k.a. money) to mess with it. I'm happily letting EF do the heavy lifting, and only sparingly using stored procedures for those one-off occasions where there is a demonstrated bottleneck due to how EF builds queries. – Sean Aug 4 '12 at 3:32
up vote 4 down vote

It depends.. we used EF on a large database and it was ok, but nothing special. However some queries simply failed to execute on the Oracle DB - if a query gets to a certain level of (undefined) complexity, then it just doesn't work. This applies to Oracle, or MySQL or any non-SqlServer DB I'm informed.

So maybe your senior guy was totally correct if your DB is Oracle, which a lot of enterprise apps are built on.

As it is, there are alternatives to EF that you should review (note that the scorecards in the linked article are from July 2010 and most likely not up-to-date for the current versions of the compared ORMs) - its pointless saying EF is fine without evaluation if you're not prepared to evaluate the other ORMs too. Maybe your senior guy just doesn't like ORMs, or maybe he's got something against EF itself.

share|improve this answer
Without a basis and versions this answer has virtually no value. – Rig Aug 4 '12 at 3:09

Not the answer you're looking for? Browse other questions tagged or ask your own question.