What are the drawbacks of linq in general.
Can be hard to understand when you first start out with it
Deferred execution can separate errors from their causes (in terms of time)
Out-of-process LINQ (e.g. LINQ to SQL) will always be a somewhat leaky abstraction - you need to know what works and what doesn't, essentially
I still love LINQ massively though :)
EDIT: Having written this short list, I remembered that I've got an answer to a very similar question...
The biggest pain with LINQ is that (with database backends) you can't use it over a repository interface without it being a leaky abstraction.
LINQ is fantastic within a layer (especially the DAL etc), but since different providers support different things, you can't rely on Expression<Func<...>> or IQueryable<T> features working the same for different implementations.
As examples, between LINQ-to-SQL and Entity Framework:
EF doesn't support Single()
EF will error if you Skip/Take/First without an explicit OrderBy
EF doesn't support UDFs
etc. The LINQ provider for ADO.NET Data Services supports different combinations. This makes mocking and other abstractions unsafe.
But: for in-memory (LINQ-to-Objects), or in a single layer/implementation... fantastic.
Some more thoughts here: Pragmatic LINQ.
Like any abstraction in programming, it is vulnerable to a misunderstanding: "If I just understand this abstraction, I don't need to understand what's happening under the covers."
The truth is, if you do understand what's happening under the covers, you'll get much better value out of the abstraction, because you'll understand where it ceases to be applicable, so you'll be able to apply it with greater confidence of success where it is appropriate.
This is true of all abstractions, and applies to Linq in bucketfuls. To understand Linq to Objects, the best thing to do is to learn how to write Select, Where, Aggregate, etc. in C# with yield return. And then figure out how yield return replaces a lot of hand-written code by writing it all with classes. Then you'll be able to use it with an appreciation of the effort it is saving you, and it will no longer seem like magic, so you'll understand the limitations.
Same for the variants of Linq where the predicates are captured as expressions and transported off to another environment to be executed. You have to understand how it works in order to safely use it.
So the number 1 drawback of Linq is: the simple examples look deceptively short and simple. The problem is, how did the author of the sample know what to write? Because they knew how to write it all out in long form, and they knew how pieces of Linq could be used as abreviations, and so they arrived at the nice short version.
As I say, not really specific to Linq, but highly relevant to it anyway.
Anonymous types. Proper ORM should always return objects of 'your' type (partial class, with possiblity of adding my methods, overriding etc.). There are doezne of tutorials and examples of different complex queries using linq but non of them care to explain the advantage of returning a 'bag of properties' (return new { .........} ). How am I supposed to work with anonymous type, wrap it in another class again?
Actually I can´t think of any drawbacks. It makes programming life a lot simpler because a lot of things can be written in a more compact but still better readable way.
But having said this, I must also agree with Jon that you should have some idea what you´re doing (but that holds for all technological advances).
the only drawback which it has is its performance see this article
Related
Can anyone please help me with a general Entity Framework question? I'm a newbie and trying to teach myself from reading and trial & error. However, I'm getting REALLY confused on all the syntax and terminology. And the more I google, the more confused I get!
What in the world are those little arrows (=>) used in the syntax? And I'm not even sure what the name of the syntax is...is it Entity Framework syntax? Linq to method syntax? Linq to Entity syntax?
Why does it seem like you can use random letters when using that syntax? the "f" below seems interchangeable with any alphabet letter since Intellisense gives me options no matter what letter I type. So what is that letter supposed to stand for anyway? There seems to be no declaration for it.
var query = fruits.SelectMany(f => f.Split(' '));
Is it better to use the syntax with the little arrows or to use the "psuedo SQL" that I keep seeing, like below. This seems a little easier to understand, but is this considered not the Real Entity Framework Way?
var query = from f in fruits from word in f.Split(' ') select word;
And, for any of them - is there any documentation out there ANYWHERE?? I've been scouring the internet for tutorials, articles, anything, but all that comes back are small sample queries varying with the little arrows or that psuedo SQL, with no explanations beyond "here's how to do a select:"
I would much appreciate any guidance or assistance. I think if I can just find out where to start, then I can build myself from there. Thanks!
There is no real entity way, there is LINQ and there is LINQ extension methods which is my opinion is much cleaner to the eyes. Also you can use LINQ not just with EE.
Language Integrated Query
LINQ extends the language by the addition of query expressions, which are akin to SQL statements, and can be used to conveniently extract and process data from arrays, enumerable classes, XML documents, relational databases, and third-party data sources. Other uses, which utilize query expressions as a general framework for readably composing arbitrary computations, include the construction of event handlers2 or monadic parsers.3
1 It is called lambda expression and it is basically an anonymous method.
Exploring Lambda Expression in C#
2 You can use anything you want, word, or letters, anything that is a valid name for a parameter, because that is a parameter
3 I find the LINQ extension methods to be cleaner, and to be honest the last I want to see is SQL like statements laying in the code.
4 A good start can be found here
101 LINQ SAMPLES
The arrow is called a Lambda operator, and it's used to create Lambda expressions. This has nothing to do with EF, or Linq or anything else. It's a feature of C#. EF and Linq just use this feature a lot because it's very useful for writing queries.
Marco has given links to the relevant documentation.
Linq is a library of extension methods that primarily operate on types like IEnumerable and IQueryable interfaces, and give you a lot of power to work with collections of various types. You can write Linq queries either in two formats, so called Method syntax and Query Syntax. They are functionally identical, but their usage is generally a matter of personal preference which one you use (although many of us use both, depending on the context it's used in.. one or the other is easier to use).
As a designer, I like providing interfaces that cater to a power/simplicity balance. For example, I think the LINQ designers followed that principle because they offered both dot-notation and query-notation. The first is more powerful, but the second is easier to read and follow. If you disagree with my assessment of LINQ, please try to see my point anyway; LINQ was just an example, my post is not about LINQ.
I call this principle "dial-able power". But I'd like to know what other people call it. Certainly some will say "KISS" is the common term. But I see KISS as a superset, or a "consumerism" practice. Using LINQ as my example again, in my view, a team of programmers who always try to use query notation over dot-notation are practicing KISS. Thus the LINQ designers practiced "dial-able power", whereas the LINQ consumers practice KISS. The two make beautiful music together.
edit I'll give another example. Imagine a logging tool that has two signatures allowing two uses:
void Write(string message);
void Write(Func<string> messageCallback);
The purpose of the two signatures is to fulfill these needs:
//Every-day "simple" usage, nothing special.
myLogger.Write("Something Happened" + error.ToString() );
//This is performance critical, do not call ToString() if logging is
//disabled.
myLogger.Write( () => { "Something Happened" + error.ToString() });
Having these overloads represents "dial-able power," because the consumer has the choice of a simple interface or a powerful interface. A KISS-loving consumer will use the simpler signature most of the time, and will allow the "busy" looking signature when the power is needed. This also helps self-documentation, because usage of the powerful signature tells the reader that the code is performance critical. If the logger had only the powerful signature, then there would be no "dial-able power."
So this comes full-circle. I'm happy to keep my own "dial-able power" coinage if none yet exists, but I can't help think I'm missing an obvious designation for this practice.
p.s. Another example that is related, but is not the same as "dial-able power", is Scott Meyer's principle "make interfaces easy to use correctly, and hard to use incorrectly."
If your "dial" has only two positions/levels, it sounds like you're simply referring to a façade.
"Progressive disclosure."
You may already be acquainted with the term because of its use with user interfaces -- e.g., "More" buttons. However, the concept is more general.
From "Universal Principles of Design," by Lidwell, Holden and Butler:
Progressive disclosure involves separating information into
multiple layers and only presenting layers that are necessary or relevant.
I call this principle "dial-able
power". But I'd like to know what
other people call it.
I've personally never heard of "dial-able power", and I don't think its an industry standard term.
In the case of LINQ, we'd refer to its design as a fluent interface.
Fluent interfaces are design so that all methods on an object return the same type as that object, and therefore makes method chaining easy. You see the same fluent design in the StringBuilder.Append overloads, fluent NHibernate, and RhinoMocks.
In the case of JQuery, it also uses fluent interfaces for method chaining, but I believe "query" or "DSL" is the proper name for its selector notation.
(Obj-C selectors use the same terminology, but describe something completely different.)
Since its described as a querying DSL, most people can infer that it takes a sequence as input and returns a sequence as output. The query notation is performs roughly the same function as XPath with more bells and whistles.
Hibernate HQL is a querying DSL on top of many SQL dialects, and in a very superficial way regexes are a querying DSL which transform string sequences into a new set of string sequences (you can, in principle, make a fluent interface for regexes, but it would probably make you claw your eyes out).
I have not found a clear comparison of what is supported with the NHibernate 3.0 LINQ Provider compared to using the QueryOver syntax. From the surface, it seems like two large efforts into two very similar things.
What are the key trade offs to using each?
LINQ and QueryOver are completely different query methods, which are added to the ones that existed in NHibernate 2 (Criteria, HQL, SQL)
QueryOver is meant as a strongly-typed version of Criteria, and supports mostly the same constructs, which are NHibernate-specific.
LINQ is a "standard" query method, which means the client code can work on IQueryable without explicit references to NHibernate. It supports a different set of constructs; it would be hard to say if there are more or less than with QueryOver.
My suggestion is to learn all the supported query methods, as each use case is different and some work better with one, some work better with other.
I have used both NH-Linq-providers (the old NHContrib for Version 2.1, and also the new for NH3.0) and also used QueryOver. With all the experience made during development of quite complex data-driven applications, I would strongly suggest NOT to use the existing linq-provider with nHibernate if you plan to go behind just basic CRUD-operations!
The current implementation (linq) sometimes produces really unreadable and also unefficient SQL. Especially joining some tables quickly becomes a nightmare if you want to optimize database-performance.
Despite all these drawbacks, I did never encounter wrong queries.
So if you don't care about performance and are already familiar with LINQ, then go for NH-Linq. Otherwise QueryOver is your realiable and typesafe friend.
LINQ to NHibernate (as of version 3.0) does not support the .HasValue property on Nullable types. One must compare to null in queries.
I started to use NH-Linq, because i was already done with LinqToSql and Entity Framework. But, for more complex queries, i have always finished with QueryOver. Reasons:
It's happen that query with NH-Linq doesn't work as expected. I can't remember exactly, but it doesn't work correct with some complex queries. Seems that is too young. And as dlang stated in previous answer, it's produce unefficient SQL.
When you learn QueryOver, it's easy to call functions, do projections, subqueries, seems to me more easy then with NH-Linq.
Good thing for NH-Linq - it can be extended, like Fabio Maulo explained here. But, similar is quite possible with QueryOver, but not so fancy as with NH-Linq :)
It seems there are two ways to build queries -- either using query expressions:
IEnumerable<Customer> result =
from customer in customers
where customer.FirstName == "Donna"
select customer;
or using extension methods:
IEnumerable<Customer> result =
customers.Where(customer => customer.FirstName == "Donna");
Which do you use and why? Which do you think will be more popular in the long-run?
Only a limited number of operations are available in the expression syntax, for example, Take() or First() are only available using extension methods.
I personally prefer expression if all the required operations are available, if not then i fall back to extension methods as I find them easier to read than lambdas.
take a look at this answer,
Linq Extension methods vs Linq syntax
I use the method syntax (almost) exclusively, because the query syntax has more limitations. For maintainability reasons, I find it preferable to use the method syntax right away, rather than maybe converting it later, or using a mix of both syntaxes.
It might be a little harder to read at first, but once you get used to it, it works fairly natural.
I only use the method syntax. This is because I find it a lot faster to write, and I write a ton of linq. I also like it because it is more terse. If working on a team, its probably best to come to a concensus as to which is the preferred style, as mixing the two styles is hard to read.
Microsoft recommends the query syntax. "In general, we recommend query syntax because it is usually simpler and more readable". http://msdn.microsoft.com/en-us/library/bb397947.aspx
It depends on which you and your team find more readable, and I would choose this on a case by case basis. There are some queries that read better in syntax form and there are some that read better in method form. And of course, there is that broad middle ground where you can't say one way or the other, or some prefer it this way and others that way.
Keep in mind that you can mix both forms together where it might make it more readable.
I see no reason to suspect that either form will dissappear in the future.
I was thinking about making something like Linq for Lua, and I have a general idea how Linq works, but was wondering if there was a good article or if someone could explain how C# makes Linq possible
Note: I mean behind the scenes, like how it generates code bindings and all that, not end user syntax.
It's hard to answer the question because LINQ is so many different things. For instance, sticking to C#, the following things are involved:
Query expressions are "pre-processed" into "C# without query expressions" which is then compiled normally. The query expression part of the spec is really short - it's basically a mechanical translation which doesn't assume anything about the real meaning of the query, beyond "order by is translated into OrderBy/ThenBy/etc".
Delegates are used to represent arbitrary actions with a particular signature, as executable code.
Expression trees are used to represent the same thing, but as data (which can be examined and translated into a different form, e.g. SQL)
Lambda expressions are used to convert source code into either delegates or expression trees.
Extension methods are used by most LINQ providers to chain together static method calls. This allows a simple interface (e.g. IEnumerable<T>) to effectively gain a lot more power.
Anonymous types are used for projections - where you have some disparate collection of data, and you want bits of each of the aspects of that data, an anonymous type allows you to gather them together.
Implicitly typed local variables (var) are used primarily when working with anonymous types, to maintain a statically typed language where you may not be able to "speak" the name of the type explicitly.
Iterator blocks are usually used to implement in-process querying, e.g. for LINQ to Objects.
Type inference is used to make the whole thing a lot smoother - there are a lot of generic methods in LINQ, and without type inference it would be really painful.
Code generation is used to turn a model (e.g. DBML) into code
Partial types are used to provide extensibility to generated code
Attributes are used to provide metadata to LINQ providers
Obviously a lot of these aren't only used by LINQ, but different LINQ technologies will depend on them.
If you can give more indication of what aspects you're interested in, we may be able to provide more detail.
If you're interested in effectively implementing LINQ to Objects, you might be interested in a talk I gave at DDD in Reading a couple of weeks ago - basically implementing as much of LINQ to Objects as possible in an hour. We were far from complete by the end of it, but it should give a pretty good idea of the kind of thing you need to do (and buffering/streaming, iterator blocks, query expression translation etc). The videos aren't up yet (and I haven't put the code up for download yet) but if you're interested, drop me a mail at skeet#pobox.com and I'll let you know when they're up. (I'll probably blog about it too.)
Mono (partially?) implements LINQ, and is opensource. Maybe you could look into their implementation?
Read this article:
Learn how to create custom LINQ providers
Perhaps my LINQ for R6RS Scheme will provide some insights.
It is 100% semantically, and almost 100% syntactically the same as LINQ, with the noted exception of additional sort parameters using 'then' instead of ','.
Some rules/assumptions:
Only dealing with lists, no query providers.
Not lazy, but eager comprehension.
No static types, as Scheme does not use them.
My implementation depends on a few core procedures:
map - used for 'Select'
filter - used for 'Where'
flatten - used for 'SelectMany'
sort - a multi-key sorting procedure
groupby - for grouping constructs
The rest of the structure is all built up using a macro.
Bindings are stored in a list that is tagged with bound identifiers to ensure hygiene. The binding are extracted and rebound locally where ever an expression occurs.
I did track the progress on my blog, that may provide some insight to possible issues.
For design ideas, take a look at c omega, the research project that birthed Linq. Linq is a more pragmatic or watered down version of c omega, depending on your perspective.
Matt Warren's blog has all the answers (and a sample IQueryable provider implementation to give you a headstart):
http://blogs.msdn.com/mattwar/