Is it recommended to use Linq instead of SQL?

LINQ itself is a part of .NET that adds query functionality to the framework. Linq is not tied to any technology, it works on an interface ( IQueryable ). The implementation of the final query (which accesses the data provider) is done by whoever implements the interface.

If you are using linq to access a SQL database then you are using some specific implementation for this (such as Entity Framework , LINQ to SQL or NHibernate ).

In terms of code security, you can not say anything. This is dependent on the implementation of the provider you are using.

What is possible to say is that one of the advantages of using linq is that your queries will be compiled, that is, depending on what is wrongly changed the compiler may generate an error.

For example, let's assume that a column is removed from the database. Similarly, removing the column also changes the system code for your class and your queries does not reference the column. If the programmer forgets to replace in a query that uses linq the compiler will generate a compilation error, because the queries will involve a property that no longer exists.

Although your questioning has already been answered, the title of your question has attracted me to share some of the other benefits we have felt in our company when using Linq if someone is going through the same decision process. Then there goes:

• Linq changes the use of Magic Strings for compiled instructions: In practice, you bring to your query's the benefits of a strongly-typed language and #,
• Linq has brought us a breakdown of self-documentation, because when creating the classes we had to revise the mapping between the tables (as we have a legacy base, we did not use contraints foreign key). It worked, but today new programmers can easily navigate from one table to another without worrying about joins . Still, the hand on the Intellisense wheel of Visual Studio makes query writing very fast;
• Linq standardizes all queries created in the .NET world. In the case of Linq to SQL, this means that you will adopt the same pattern that can be rendered in several dialects * of different databases. It is worth remembering that although the SQL is a ANSI language , it is difficult to restrict itself to the default (take SQL functions substring and top N as an example);
• And if you still need to use String's to form your query dynamically without too much hassle, you can turn to Dynamic Linq .

And yes, we have performance problems for poorly formed queries every now and then, but we'll find a way. In short, I say that it is (very) worth it.

[*] In our case, we are using Linq to SQL implemented by the excellent NHibernate that already brings support for the most common databases .

Yes, using LINQ forces the programmer to protect your code against SQL injection.

Yes, LINQ is sometimes slower. But there is more than one way to detect and resolve these issues.

Yes, I have used LINQ extensively to communicate with the database and recommend it. Especially in the version for Entity Framework, since Linq-to-SQL is no longer updated.

In my experiments, LINQ has several qualities, yes, but it has its limitations as well. I have already passed, for example, a Dataset so large that LINQ broke the whole program. Using for { ... } , you can do the same thing but extremely faster.

I think this slowness comes from the extreme 'overhead' that using LINQ brings, being that in the background, .NET makes a for { ... } the same way.

(Sorry for the Portuguese there: P)

What I can say from LINQ, in my point of view is only worth to make simple, simple registrations. Even so, I see no advantage. Well, Delphi has always been a very fast development language, and it does exactly what the link does, strange that I'm talking about it more, you see, when you use Delphi components like ClientDataSet, it will do a mapping of your table and there it adds all the basic features of a registry, the problem is that it does a mapping of the table according to the database you are using and this way it ties you to the bank, if you need to change banks you would have problems, several. In Linq this same mapping of the table happens, it ends up creating the more classes it will also tie the bank you are using, and when you use SQL, you create each class separately using the types of primitive fields that will serve for any database, basically you have the connection to the database and the classes that represents your tables, do not have a direct link, so in the end, it will be pure SQL out that you will not need to learn a new LINQ syntax. So for me in my point of view does not compensate, I develop using a project for the Repository, Domain, Application and a project for the presentation, I think it's worth you to do a small project, to test more for me LINQ, only It's good to do simple registration. About SQL Injection, just use the @Html.AntiForgeryToken () in the HTML and in the [ValidateAntiForgeryToken] controller.