Linq to Entities vs the Database
I’ve been working with sql server for a long time. I like sql, I like the immediate feedback that I get from working in SQL Management Studio, and because I do have a lot of experience I can quickly construct efficient queries.
I also recognize the value of having business logic in a central location, and understand how difficult it can be to support a system when there are little bits and pieces of business logic scattered among various layers and in different code bases.
But there are also no silver bullets.
A lot of folks seem to believe that Linq to Entities can replace stored procedures, views and other core database functionality, and that transactions should be handled on the client side rather than on the server.
In some cases, perhaps a lot of them, this is true. But there are no silver bullets, and there are always exceptions.
Stored procedures outperform Linq to Entities if properly written, sometimes by many orders of magnitude. Views can be used to easily perform data magic, like making two tables look like one, redirecting queries to another database, or hiding or renaming columns. Triggers can guard database integrity in a way that is impossible from any external application. And sql functions can be used to perform query tricks that are either impossible or very difficult to do using Linq.
Linq is great, especially for inserting, updating or deleting data. But it can’t completely replace database-level logic, at least in complex applications.
It’s important to remember when working on complex applications that there are no silver bullets and just as it would be very difficult to put all business logic in the database, it will also be very difficult to put none there at all.