Is Entity Framework more than a very time consuming way to save a little time?

I got about t开发者_运维百科wo chapters into a 1000+ page on entity framework and got discouraged and went back to good old stored procedures.

What is the consensus (if any) on Entity Framework? It would be interesting to hear from folks who have finished projects based on EF to see if they think it was worth all the effort.

I've been tinkering around with T4 templates a bit and found a way to generate my SPROCs and DTOs just the way I like them without messing around with EF. Am I missing something?

I personally like the abstraction and easy integration with LINQ that is possible with Entity framework, having an ORM instead of interacting with SQL server directly is huge in terms of productivity.

On the other hand it's by no means complete - for anything that requires bulk-processing, i.e. large table delete's or full text search you still have to do store queries - but at least it minimizes the number of them that I have to deal with to those scenarios.

I've been tinkering around with T4 templates a bit and found a way to generate my SPROCs and DTOs just the way I like them without messing around with EF. Am I missing something?

Not necessarily. The process you described is the basic reasoning behind any ORM.

The Entity Framework provides a few things that your T4 templates may not:

1. A Microsoft-standard way of creating data classes
2. The ability to scale into large applications
3. The ability to support different data stores with the same code.
4. Flexibility

EF is part of a larger picture that encompasses things like built-in data validation, lazy loading, multi-tier design, and testability. If you are building very small applications that will never grow into larger applications, you may not need these things.

There is definitely a significant learning curve when it comes to any ORM. It is worth it to stick it through, and you'll eventually get to some milestones in the process where you'll really see the benefit of a flexible ORM like EF or NHibernate.

You're basically learning a complicated API, and once you get proficient enough in it, the time you save will dwarf the time you've invested. That is assuming that you continue to use it for future applications.

For basic CRUD applications, Entity Framework or any decent ORM will save you a ton of time. Yes, there is a learning curve. As with most technology, you can stay with what you know or you can invest to learn something that may be better. ORMs are definitely better.

Does your sproc return a data reader or data set? How much code are you writing (with T4 or not) to translate that data reader/set into an object class? In the end, if you don't use an off the shelf ORM, you generally end up having to build your own, which is a huge mistake.

How have you decided to split business logic (for non-CRUD scenarios) between the sprocs and the application classes? With an ORM, the business logic pretty much never gets split, it all belongs to the application classes, which is significantly easier to maintain.

I've done it both ways, and T4 leaves a lot to be desired as a data layer solution.

Even with an ORM, there are scenarios (for performance or whatever) where you will use sprocs and that's okay, but you may never need more than a handful of sprocs for a database with hundreds of tables.

ORMs offer a lot of features that you may not need today, but you'll be happy you don't have to build them yourself when you do need them.