views:

510

answers:

4

I am currently reading Albahari's C# 3.0 in a Nutshell book and on page 292 it says this about LINQ:

LINQ follows a demand-driven pull model, rather than a supply-driven push model.

What does the above statement mean?
And what is the difference between a pull model and a push model ?

+3  A: 

This means that your LINQ queries will pull data from a datasource based on your queries and will only be done when executed. As opposed to a push model, where the server generates the data on its end and then pushes the data to a client. A push model would be like Blackberry Enterprise Server where email is pushed to the Blackberry device instead of the device constantly having to query for it. This also means that any changes since your LINQ query won't be reflected in your dataset.

jasonh
+1  A: 

In a pull model the processing is initiated by the consumer of the result (the result is being "pulled" through the processing pipeline).

In a push model the processing is initiated by the producer of the data (the data is "pushed" into the processing pipeline).

So the data that will be processed is what is being acted upon in either case and the "direction" (push/pull) it is moving is relative to the person triggering the processing.

dmo
I recognize that avatar! http://www.warrenrobinett.com/rockysboots/
Jeff Atwood
I loved playing Rocky's Boots and Robot Odyssey on the old Apple II+ as a tike! You're the first to recognize it. :-)
dmo
+5  A: 

I am the client, I need something, pull it from the server.

I am the server, I have something, push it to the client.

Soviut
Why exactly was this downvoted? Not wordy enough?
Soviut
+3  A: 

To really understand (and appreciate) the distinction you'll need to consider the difference between a statement and an expression. As you know, imperative programming languages like C# and VB traditionally use statements that are executed in a sequence to accomplish some goal. In such a scheme, you retrieve the data and then push it onto some other statements. Functional programming, in contrast, tends to use expressions which are just values. In the case of LINQ you declare a query expression which at some point will evaluate to a value, but it doesn't do so until it's needed. This lets you as the programmer concentrate more on what your program does rather than how it does it. More broadly, laziness describes an evaluation strategy that is typically employed by functional programming languages. For instance, if you had a declaration like the following:

let x = 2 * y + 7

a lazy programming language would not bother evaluating the expression until it explicitly needs to but in the mean time you can just refer to it by the binding x. In the same way, when you make a declaration like the following in LINQ:

var collection = from s in S where predicate(s)

you've declared an expression and bound it to collection but you don't actually need it until you do something with collection. So you can declare it anywhere in your code and not worry about it taking up memory when it's not being used and thus you're now thinking more about the problem you're trying to solve rather than specifying in exhaustive detail how the computer should go about solving it.

So, in summary, in an (eager) imperative style of programming you grab the data and then push it onto some function that will act on it. In a (lazy) functional style of programming, you declare an expression and at some point it will be evaluated when it needed, which, in the case of database stuff means the function that needs the value of the query expression will pull it when it needs it. Push/Pull really is poor terminolgy though.

Rodrick Chapman