Menu
Are there any good Reasons not to use LINQ in my projcts? We use .Net 3.5 and VSTO 3.0.
429
It is slightly slowerLINQ syntax is typically less efficient than a foreach loop. It's good to be aware of any performance tradeoff that might occur when you use LINQ to improve the readability of your code. And if you'd like to measure the performance difference, you can use a tool like BenchmarkDotNet to do so.
LINQ to SQL was the first object-relational mapping technology released by Microsoft. It works well in basic scenarios and continues to be supported in Visual Studio, but it's no longer under active development.
Readable code: LINQ makes the code more readable so other developers can easily understand and maintain it. Standardized way of querying multiple data sources: The same LINQ syntax can be used to query multiple data sources. Compile time safety of queries: It provides type checking of objects at compile time.
Personally I can't see why you wouldn't want to use it, it makes code much more readable.
With that being said, LINQ can sometimes be detrimental to performance in certain scenarios, that would really only be my reason for not using it.
163
The other answers have implied this, but here it is explicitly:
The term "LINQ" can refer to the overall set of technologies for Language INtegrated Query. These technologies permit a LINQ Query to be turned into an expression tree. That tree can be executed at a later time, by a "LINQ Provider".
The LINQ Provider looks at the expression tree and converts it into, for instance, SQL statements, or XML DOM navigation, or navigation through an object graph. These providers have names like "LINQ to SQL", "LINQ to Entities", "LINQ to Objects", etc.
There could be reasons to not use a specific provider.
Many of the individual LINQ providers come with additional tooling (some would say, "baggage"). This tooling helps provide some of the most common "pros and cons" about LINQ.
In particular, LINQ to SQL provides a direct, one to one mapping to the database schema. Each LINQ class corresponds to a single database table. If the structure of the database changes, then so does the code. This can be mitigated to an extent by using views.
I believe that LINQ to SQL is limited to Microsoft SQL Server. Also, Microsoft has stated that LINQ to SQL will not be a priority investment going forward.
LINQ to Entities is part of the ADO.NET Entity Framework (EF). EF provides for modeling your entities in a more abstract, conceptual level. For instance, you might have a Person entity that takes data from two tables that have a one to one mapping. Code accessing this entity need not care how the tables are broken out in the database.
I believe that LINQ to Entities is meant to work with many ADO.NET providers, not just SQL Server. Also, this is where Microsoft says it will be placing its investments going forward.
In both of these cases of LINQ to "some database", it's almost always going to be the case that a experienced SQL developer and/or DBA can write better queries than will be generated by LINQ. If performance is the top requirement, I believe that LINQ to Entities can map stored procedures into methods on the entities.
The big benefit of these LINQ providers is that you don't need that experienced SQL developer or DBA when you're working in an environment where performance is not the top priority. This frees them up to optimize queries that actually require their expertise.
Another reason not to use these directly is if you have security considerations preventing your users from having SELECT permissions to the database tables. In that case, use views or stored procedures.
42
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
