LINQ – Pros, Cons
December 20, 2011 § 1 Comment
This is a short, kind of myth buster article on LINQ. For beginners.
If you don’t know LINQ yet.
LINQ is more a syntactic feature in C#, than a programming feature.
All compiled code are similar whether it uses LINQ, or just implements same stuff without LINQ.
The basis of the above statement is that.. after C#/VB.NET compiler compiles the code with LINQ queries and expressions, it is translated into (auto-generated into) normal method calls or object instances as appropriate for the logic… which would have been similar to what you might have written if you didn’t use LINQ.
An Example is.. Writing code that creates an XML string using XML.Linq is same as code that creates an XML string with XML DOM or XMLDocument… because once compiled all XML.Linq code is translated into XMLDocument or DOM based code. When you use XML.Linq, you allow C# compiler to write all the important code, while we syntactically do short and crisp queries, expressions, and methods.
Why is LINQ Good
Because it generates the standard code that many developers write in different ways. It is like dragging some objects on to your dashboard, link them together, and clicking Start, like in futuristic movies .. and the system already starts functioning.
LINQ is like futuristic programming.
Instead of doing the same old code many times or creating our own data adapters, xml adapters etc., we use LINQ which generates our adapters when the code is compiled (not on the fly during runtime, but at IL level itself), and attaches the data types variables should have on the fly.. so that code writers can simply use the ‘var’ type in most places for variables.
LINQ – to – SQL
LINQ to SQL, is a set of interfaces, classes, that allow us to create LINQ queries or expressions on our data sources the easy way.. instead of creating data layers with data adapters and entity objects.
By doing LINQ-to-SQL we allow a C# / VB.NET compiler to generate our data adapters and entity objects for us in the IL level code that is run by the CLR.
Saves us time, planning, building code or libraries or patterns .. which can all now be generated quickly the standard way by the compiler.
Makes it quicker.. so in a few minutes you can query your DB directly, or through its SPs.. without writing one line of data layer code in C#.
LINQ – to – Objects
Allows us to create query-able objects and use them.. load data into them or query data from them.
Why LINQ-to-Objects, We already have collections
But collections are only enumer-able, not query-able. You can’t do a where, select, etc., on collections, like we can in LINQ objects.
Designing objects that powerful is what LINQ-to-objects is all about.. and again without planning, designing and creating them… and just allowing the compiler to auto-generate them, with all the required infrastructure to allow querying.
LINQ – to – XML
Allows us to read, create or modify XML without all the overhead of XML DOM objects and appendchild and selectnodes we used to do.
Is LINQ synonymous with High performance
It is.. if we understand how to use it properly.. so that the compiler can generate high-performing code. If we write complex expressions in such a way that the compiler translates it into many method calls nested within each other and many loops are generated in the resulting translation by the compiler, then it is not high performing.
Just because LINQ is used doesn’t mean code is better performing.
And all that we read about performance on LINQ-to-SQL, or LINQ-to-XML or LINQ-to-Objects is about what would make the compiler generate good, performing code when our LINQ use is compiled…not that LINQ would magically create better performance than normal way of doing the implementations without LINQ.
- Saves a lot of Development time.. so we do only the wiring needed, and the compiler takes care of all the actual standard implementation blocks that it has to be translated into. Time saved is the biggest advantage of LINQ, more than anything else.
- LOC – lines of code decreases considerably.. of course only in medium/bigger implementations.
- Many other core Advantages can be said of LINQ.. but they all wrap up to the above point.. that LINQ writes the blocks for us.. so a LINQ-to-SQL guy would say LINQ generates all the data layer, entities, creates neccessary data type, accepting DB changes is easier, etc., as advantages.. but all the guy means is he is just doing drag-drops or clicks and code is auto-generated and only wiring is needed.
- A beginner level C# or VB.NET developer, who has had little SQL querying experience can quickly code great with LINQ and interacting with data sources, objects and xml… without needing to understand in a big way the tech involved in ADO.NET, XML DOM, OOAD.
- There are already tools and applications which allow non-programmers or business users learn basic querying constructs, write LINQ queries, and see data in reports the way they want. LINQ-pad is basic example.
- LINQ is futuristic programming.
- Beginners who get very used to LINQ, find it hard to improve performance of their LINQ code blocks because they are not strong with tuning the sources that LINQ works with. (and also may be because they don’t understand performance tuning of LINQ expressions for the same reason)
- LOC – Decrease in lines of code may not be big or important on some implementations, where the amount of query-able logic needed is less. i.e., where scope for using LINQ is less.
- Readability of code decreases considerably.. especially in bigger implementations where datasources are big or huge.. and it is further worse if code has many delegates + anonymous methods.. as delegates/anonymous methods are commonly used along with LINQ. Even experienced LINQ programmers will find too many anonymous methods, delegates, and LINQ queries / expressions complex to debug.
- Learning LINQ and using it has an overhead for an experienced developer. Anonymous methods, Func<>, Action<>, predicates, etc., there are so many shortcut programming to learn and proper programming to un-learn.
- Sometimes, programmers who can’t forget their normal programming model for a while when using LINQ.. end up rethinking or reverting their use of LINQ expressions.. especially when the expression or query doesn’t return what they expected.
- If all or most developers in a team don’t know LINQ, and LINQ is attempted to be used, it causes time delays and confusion with working or maintaining the code, rather than saving time.
Most of the above Cons are arguable.. especially because of the strong first point in the Pros.. “shortening & auto-generating standard code saves time”.
At the syntactical level / readability level, though, LINQ vs normal code writing, is almost similar to debate on SMS vs proper text messages.
Use of LINQ for small, one time functions should be avoided.. sometimes it is just syntactic sugar or stylish.
LINQ should rather be used to fully automate implementation for things like parsing or creating XML, working with Databases or even multiple datasources like xml, rss, atom, database tables, and objects.