Is Entity framework reliable enough to use in a Corporate Project? Should I use Entity? [duplicate]

Question

Possible Duplicate:
Is Entity framework reliable enough to use in a Corporate Project? Should I use Entity?

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.

Answer 1

I am actively discouraging the use of stuff like the Entity Framework in my organization primarily because:

• I like to be in control of what my system does. Mysterous black boxes that somehow do what I want are not how I want to support an enterprise system. Unless, of course, we developed the mysterious black box ourselves! :)

• I find that these great frameworks are generally optimized for flexibility. There is often a trade-off between flexibility and (performance + simplicity).

• The approaches I advocate in my organisation favour architectural frameworks over frameworks that actually do stuff because they are language- and tool- agnostic. The same principles can be applied across the organisation regardless of development envionment or solution, and even withstand a change of toolset.

• The more you have to think about something, the more familiar you become with it. Thinking about how and why the database is structured helps with deciding how and why your entities are the way they are (although that is the absolute extent of any dependency)

• And because one of my general principles are: "Shortcuts are seldom short."

So, it's not really about reliability as much as an overall maintainability approach. I'm sure if you get the Entity Framework to do what you need to do it's as reliable as anything you do yourself, for this project.

And it's not fair to be 'chewed out' for the decision you made - if someone wanted a particulat approach they shoul have specified it in the first place.

Answer 2

Just as a point of clarification: Entity Framework is built on ADO.NET. As a matter of fact, it's official name is ADO.NET Entity Framework. They are not two separate and competing products.

To answer your question, yes, Entity Framework is very capable for a corporate application. As a matter of fact, some would argue that to forego using an established ORM (such as EF or nHibernate or similar) and use ADO.NET directly is irresponsible, due to the unnecessary overhead of reinventing the wheel when it comes to data access and object-relational mapping.

"If you’re writing ADO.Net code by hand, you’re stealing from your employer or client."

"If you have to map relational data to objects, you must use an ORM."

Answer 3

I agree with @Michael, although here's my opinion.

Using either ADO.NET or EF (or Linq to SQL or NHibernate or anything else) nowadays comes down to a religious preference. There are differences in these frameworks, although they all are capable of doing what they do best.

As @Michael mentioned, some people do not like 'black boxes' and prefer doing it the way they want, so they know what is happening behind the scenes and gets more fine grained control. If you're happy to write your own framework, I'd say go for it. I personally like using a framework, because I'm not the only one using it, and it is widely tested, can get answers to my questions, and don't really have to test that framework so faster and easier development. On the other hand, if you hook up a SQL profiler, you'll see that there are quite a bit of noise in there and it is hard to track what's going on where as if you're using your own code, you'll know exactly why every single query is executed.

ADO.NET and EF are very feasible for cooperate applications. They are reliable and stable as they can get. (unless you're playing with a beta version.)

If you used Entity Framework, it worked well with your development, and you're happy about it, I do not see why you would suddenly move everything to ADO.NET (or any other framework).

It doesn't hurt to learn another framework, but your senior developer criticising your decision is not a reason to re-write your code. (Only thing that can come out of moving to another platform without a reason are bugs, stability issues and more bugs) As a wise man once said 'Don't fix it, if it ain't broken'.

If he says your code (or the framework of choice) is not reliable, ask him to prove it.

I use EF Code First, for my personal work, simply because it is faster development, and don't have to worry about how the database is created/managed. (Which I'm happy about, because I'm not a 'database guy', and happy to leave it as a ''black box. But your view may be different.)

About EF 5. There are new additions as well as bug fixes coming to EF 5. you can have a look here for what's new. I think you need .NET 4.5 to run EF 5 beta. (Note: If you're trying out beta, expect bugs and 'reliability and stability issues', because .. well.. it's beta.)