Is Entity Framework Overkill for Web Applications?

Question

Let's say we are developing an E-Commerce Web application for a small to medium sized business. Let's further assume that the business is likely to scale over time. In other words, the product line will typically grow.

Up to now I have developed n-tier solutions using ADO.NET and stored procedures with the help of the SqlHelper class. For bigger applications I have used Enterprise Library (2.0).

I would like to move towards an ORM-based approach and am starting to learn LINQ as well as making the switch from ASP.NET Web Forms to ASP.NET MVC. I do not want to go with LINQ-to-SQL. The question is not whether an ORM is required but if the Entity Framework ORM is overkill for such a project. I don't mind a learning curve if it is warranted for the task in hand.

As regards "overkill", I would like to know if:

• EF is faster than someone with the correct skills coding queries manually
• EF leads to unnecessary code bloat
• EF unnecessarily shields devs from code-level details of their queries
• LINQ-to-Entities is suited for projects of this size

In fact, if anyone thinks that an ORM is overkill for such project I'd like to hear reasons why. What prompted me to ask this question was the following article:

http://razor.preneer.com/razor/post/Entity-Framework-is-the-wrong-direction-for-web-developers.aspx

Answer 1

Definetely not an overkill. Go ahead and use EF.

Answer 2

EF is not overkill for web apps.

I disagree with a lot of what is stated in your referenced article. I do agree devs should have decent skills with SQL BUT ORMS do a great job in getting a devs job done more quickly.

• Speed of ORMS - They are getting better all the time & they allow you to call SP's or modify the queries to get max speed when necessary. There are also great profilers out there for monitoring ORM performance like EFProf.

• Slows down the coding process - Really!!! Once learned it speeds it up.

• Devs needing to know SQL - I agree. However, ORMS especially with LINQ syntax often allow devs to right more complex SQL than they would have on their own.

• Devs write efficient queries already - REALLLYYYY!!!! Just ask the DBA his/her thoughts! I happen to think I do but so does everyone else. See the problem. :-)

• Code Bloat - Have to disagree, especially with ones that have LINQ.... It often makes the code more readable and reduces the line count often.

• Forget about LINQ - This ship has sailed. LINQ Rocks!!!! Go with it or be left behind. It's not just used in ORMS. It can be used against, arrays, objects, XML, files, twitter and the list goes on and on.... Get to know LINQ.

The article talks about some of the inspiration of the latest developments out of MS as coming from Ruby on Rails. ROR has an ORM based on Active Record in it.....

ORMS are good. They don't have to be used everywhere and everytime but they are good and should be considered.

Answer 3

EF has a learning curve, but anything new does. EF is not overkill, but as per any system being written use the right technology for the right project.

Answer 4

Looking at the article, the first thing I would see and disagree with is this:

I strongly believe that modern web developers should:

•Love databases.

•Write highly efficient queries.

•Minimize code.

•Design self-evident user interfaces.

•Work quickly.

I am not sure how many people view web development, but in my mind a web devloper should focus on functionality and business rules. The pure database and SQL code should never be done by someone on my team that would be more productive writing business functional code.

This is where Entity Framework comes into play. It is considered a Rapid Application Development tool (as are most other ORMs). These tools are built specifically to allow you to focus more on how to fulfill the user requirements and less on what the right way to write a query is.

With that being said, I would also say that using the tool naively could be dangerous. When you use Entity Framework you still have to be cognizant of the implications of using the object graph that you are requesting.

It is by far not overkill, the tool is very simple to use and simple to learn. I would argue that it is easier to "fix" an Entity Framework rather than fixing a raw SQL Query and ADO transaction set.

On smaller projects my base recommendation is almost always go with some type of ORM. On enterprise applications you have to be a bit more careful and it entirely depends on budget :-).

Answer 5

Although this is a general answer be wary of any opinion which has these comments in:

"X tool stinks, I write in Y tool and I can do it faster than in X tool."

Or course a Latin speaker speaks better in Latin.

Answer 6

It actually depends on the complexity of your data model rather than the type of application it is.

If you have a relatively simple data model, then EF may be overkill (if you don't know it yet). Linq-to-SQL may be a better choice (less learning curve, though it also has limitations such as no many-to-many mappings).

If your data model is more normalized, rather than just table based then EF will definitely pay off in the long run, or nHibernate, or any other more advanced ORM.

The article you link to seems to indicate that ORMs in general are bad, not just EF. When confronted on his points, he seems to back off them to some degree. It seems like he is trying to justify a blanket concept (that new developers should have to learn low level coding, particularly SQL, before going to high level frameworks) by inventing questionable points.

Answer 7

An ORM can be quite useful, if used properly and you understand what it's doing for you. You should definitely use one, if you already have some understanding of database design and querying.

The point of the article, primarily, is that the concept of not having to learn anything about database design and querying somehow makes your life better is a fallacy. I prefer very thin layers of abstraction between code and database - I feel that lets me focus more on good user experience.

I personally feel the press behind EF is encouraging new coders to ignore some necessary basics. I've worked with some of them, and think they were done a disservice.

Of course, there are those that will very strongly disagree. No problem!

I know developers who started off loving it, and now don't. But I also know developers that love EF and swear by it.

I've used EF, LINQ to SQL and NHibernate and others over the years.

Best advice: give it a try. Come to your own conclusion.

(Disclosure: I'm the writer of the article you cited).