Linq to Entities, not wrong or right

At this point in my career, I have had the pleasure of having Linq to Entities be made both mandatory and forbidden by management decree. All I can say is, whether you want to ban L2E or mandate it, you are wrong.

If you have a simply structured application Linq to Entities can save you an absurd amount of time that can be used to do things like make your application more usable. For applications whose databases can be described by simple one to many, or many to many relationships, Linq to Entities can be quick to code against, have reasonable performance, and present a shallow learning curve. For more complex reporting pages, Linq to Entities can easily leverage stored procedures to increase performance. Yes, there are risks such as an ignorant programmer unintentionally doing multiple full table scans; however, it is unlikely that a programmer who can not be trusted with L2E could be also be trusted to remember to use the count(*) aggregation in SQL.

However, if your database schema is not so simple, you might run into issues with Linq to Entities. If your database has self referencing tables, is denormalized, very complex, or just generally misshapen from consultant raiders, L2E may not be worth the hassle. There is nothing wrong with straight up SQL, it has always worked, and it still does. In the hands of an experienced developer, by-passing Linq to Entities in favor regular SQL and Ado.net can give you access to some very powerful optimizations without sacrificing a robust code base. Although, stored procedures can also be used with L2E to increase performance, this sometimes adds business logic into the database.

In software architecture and patterns, there is no always best solution. Patterns need to be applied on an as needed basis by someone who actually understands the benefits and drawbacks of a given pattern. Linq to Entities is the same way; it has many benefits and drawbacks and therefore needs to be used as needed.