Surprised by LINQ | The Coffeehouse

Sampy
This will be the sixth time we have destroyed it and we have become exceedingly efficient at it

I have to say that before I got my hands on VS 2008 and really sat down to write serious code, I wasn't that excited about LINQ. I thought the DB access would be great for small or one-off apps and the XML stuff was nothing new. Some of the LINQ to objects stuff looked alright but I still wasn't that impressed.

Now that I've spent some time with it, I love it. The amount of operations that we do that can be expressed as set operations (projection via Select(), filtering via Where(), grouping, etc.) is nuts. I can rewrite entire methods as one-liners that just use query clauses properly. I'm writing a World of Warcraft combat log parser at home and so far it's basically 2 lines: create a RegEx, run a query that parses the file into an object graph.

Extension methods are quite nice as well. I can write Converter classes that move between our internal representations, for example Entry, to an external proxy object, Post, for returning from Web Services. The beauty is that Entry and Post have no idea about each other but I can still write thisEntry.ToPost(). I get awesome separation of objects and great syntax.

Anyone else out there having a good (or bad) time with LINQ?

Dr Herbie
Horses for courses

Sampy wrote:
I have to say that before I got my hands on VS 2008 and really sat down to write serious code, I wasn't that excited about LINQ. I thought the DB access would be great for small or one-off apps and the XML stuff was nothing new. Some of the LINQ to objects stuff looked alright but I still wasn't that impressed.

Now that I've spent some time with it, I love it. The amount of operations that we do that can be expressed as set operations (projection via Select(), filtering via Where(), grouping, etc.) is nuts. I can rewrite entire methods as one-liners that just use query clauses properly. I'm writing a World of Warcraft combat log parser at home and so far it's basically 2 lines: create a RegEx, run a query that parses the file into an object graph.

Extension methods are quite nice as well. I can write Converter classes that move between our internal representations, for example Entry, to an external proxy object, Post, for returning from Web Services. The beauty is that Entry and Post have no idea about each other but I can still write thisEntry.ToPost(). I get awesome separation of objects and great syntax.

Anyone else out there having a good (or bad) time with LINQ?

Liking linq to SQL a lot since I started playing after seeing the talks at the Heroes Happen Here event in the UK.

I have yet to test performance -- how does Linq to SQL compare performance-wise to table adapters? Has anyone done any benchmarking?

Herbie

stevo_
Human after all

I love linq, sadly - I think its release was marred by people thinking it was just an ORM.. where as its a much more generic concept.

One of the interesting things in the C# implementation is their seperation between the language and .NET, like with foreach (where C# only cares that GetEnumerator() exists on the type, not ienumerable implementation) the monads for linq only rely on the monad name with compatable signature existing on the target type (this can even be an extension method).

Its really well executed, it's one them things (like say - generics) that you would be an arse to complain about, because it adds such a rich and extensible concept into the language..

Isshou

Two of the things I like about LINQ from testing and learning I've done: joining data from different sources (even source types) and the defferment.

LINQ provides several ways to join (inner, outer, left outer), stitching, nesting queries insides queries, or otherwise manipulate queries based on different sources of any type that has a LINQ to (X) provider written for it. So do a nice XML and Object merge, or a even some weird XML-SQL-Object merge. Even joining is just a small cavet of LINQ, it really is quite expansive.

LINQ statements are defferred, so no more writing the statement multiple times or calling a common method multiple times, any time you cause an iteration through the data set (foreach(), ToList()) the LINQ computes and returns to you an up-to-date set of data. This is especially important if you're dealing with databases or objects which can be changed separately from your execution.

I think the downside is that the LINQ statements and supporting classes can get complex far too easily, rendering less readable code which needs to be well documented.

wisemx
Live it

LINQ is the whip!
Love it. Big Smile

elmer
I'm on my very last life.

I'm need to sit myself down long enough to learn how to use it, because at first glance I can't quite see how to apply it to my apps that build SQL query strings based on page request logic.

e.g. SELECT "...I have no idea yet, but I'll work it out when you ask me..." type of thing.

JChung2006

LINQ to Objects is the bomb. I love that code. LINQ to Objects + PLINQ = Crazy Delicious.

Duncanma
Just Coding for Fun...

I was digging around on the topic of web slices, but I ended up at this site: http://www.linqpad.net/

an interactive linq querying tool, great for learning linq if you, like me, haven't a clue how to get started.

vesuvius
Das Glasperlenspiel

Everyone that has posted has not used Linq in production quality applications, and as such are inadequately equipped to provide sufficient detail.

Linq is very powerful. Linq to Objects and XML are more than useful. They are staggering! Linq to SQL is an absolute no-no for realworld applications. The reasons are;

It is incomplete, and support for things like n-tier architecture are at best tenuous. I've no doubt this will have improved by the next version. You end up having to introduce complex workarounds to get this to work, when present infrastructure is more mature and better equipped. Whenever you introduce technology to an app you have to be able to justify the raise in abstraction for the benefits. Linq at present is very expensive in this domain. Anyone that argues different, clearly falls into the category of people that have just fooled around with it.
Where do you want your data/number crunching to occur? On the server or on the client? With things like WPF being resource heavy, I choose the server so my linq queries must reside there and the client resources can be utilised for graphics and speed. In the age of concurrency I prefer my parallel for loops etc to occur on a server or servers rather than burdening my client machine. Transact SQL is a far purer functional language than Linq so please stop 'harping on' about how C# or VB add funtional programming constructs. If you know T-SQL well you're a far better functional programmer than you ever will be with C# or VB. The new SQL 2008 IDE introduces things like intellisense. There is a competition going on between .NET and SQL now. The SQL team have learnt a lot from the implementation of Linq to SQL and are introducing features programmers are used to as much as C# introducing anonymous types.

Use Linq and enjoy it but remember it is not the one size fits all solution. Nowhere near it.

stevo_
Human after all

I'm sure you didn't mean your post to sound as big headed and arrogant as it came across, but a couple of points about your contribution to this topic:

The topic is talking about Linq, where as you've gone on to rant about a single implementation of Linq (Linq to SQL)..

While I don't think Linq to SQL was the best example of an ORM, I don't think its fair that you should rate Linq because of that..

Your first statement is is the worst, and I'm sure you must of miscommunicated your point, Linq itself is an abstract and pretty passive concept - saying that people cannot judge it because they haven't used it in a production app (by the way - how do you know this?) isn't very well thought..

Pace
In The Mix...

vesuvius wrote:

The new SQL 2008 IDE introduces things like intellisense.

Ive had intellisense in SSMS and EM since 2000 Cool

I couln't work to half my capacity without it, especially if you are working on an area where you dont know the schema properly [6]

Ray6

Is no-one really worried about having all that SQL mashed in with your c# code?

Doesn't it make maintenance difficult?

Dr Herbie
Horses for courses

Ray6 wrote:
Is no-one really worried about having all that SQL mashed in with your c# code?

Doesn't it make maintenance difficult?

We already have a lot of SQL mashed in with our C# code in the form of TableAdapters (and the embedded SQLCommand instances), so moving that to Linq to SQL wouldn't adversely affect SQL maintenance. We do complex stuff in SPs, but CRUD stuff we do in table adapters (not my decision, not my design).

Herbie

vesuvius
Das Glasperlenspiel

stevo_ wrote:
I'm sure you didn't mean your post to sound as big headed and arrogant as it came across, but a couple of points about your contribution to this topic:

The topic is talking about Linq, where as you've gone on to rant about a single implementation of Linq (Linq to SQL)..

While I don't think Linq to SQL was the best example of an ORM, I don't think its fair that you should rate Linq because of that..

Your first statement is is the worst, and I'm sure you must of miscommunicated your point, Linq itself is an abstract and pretty passive concept - saying that people cannot judge it because they haven't used it in a production app (by the way - how do you know this?) isn't very well thought..

I am not big headed and like a lot of people here on nine and there is always the risk of being miscontrued. People like Dr Herbie have far more experience than I.

I did and have noted that Linq to Objects and XML are Staggering. Nothing more to add there.

The rant about Linq to SQL is a valid and pertinent one. Yes linq is abstract and passive but no-one is stating the real world problems with using it. That is the problem with being passive. This is the problem when you try things out, you miss the small details that make working with Linq or anything for that matter an absolute headache.

I will give you a few examples.

Try and databind to anonymous types using a winfoms datagrid view and have CRUD and formating of the datagrid view. Ensure that this using modulable patterns and practices. Compare the volume, cleanness, understandability and separation of this code, and lets say, table adapters
Try to databind to custom business objects in another layer
Proceed to use the SetColumnError method using Linq validation and you soon find that you have to write oodles of code

These are factors you consider when writing applications, that you don't consider at the passive stage. One is enamoured with what it appears to solve. Another factor is just the sheer complexity you introduce after creating 20 or so business classes. You soon realise that your program has very quickly become very very complex, just for the benefit of adding queries in code.

vesuvius
Das Glasperlenspiel

Dr Herbie wrote:

Ray6 wrote:Is no-one really worried about having all that SQL mashed in with your c# code?

Doesn't it make maintenance difficult?

We already have a lot of SQL mashed in with our C# code in the form of TableAdapters (and the embedded SQLCommand instances), so moving that to Linq to SQL wouldn't adversely affect SQL maintenance. We do complex stuff in SPs, but CRUD stuff we do in table adapters (not my decision, not my design).

Herbie

Table adapters offer a far cleaner way to deal with queries than Linq to SQL. The present system is now mature with table adapter managers that make cross table updates a cinch. Linq will catch up probably next version. It's the design time RAD you have with the tools that are non existant with Linq. Syncronisation services are also new to SQL compact that only work with table adapters as Linq to SQL compact is not supported. If you have a distributed application this does really improve user experience.

I still think that Sprocs with SQL plus concurrency makes for the best performing application. Linq ultimately generates SQL queries, it does not have it's own way of dealing with data so knowing SQL well puts you at an advantage.

vesuvius
Das Glasperlenspiel

Pace wrote:

vesuvius wrote:
The new SQL 2008 IDE introduces things like intellisense.

Ive had intellisense in SSMS and EM since 2000 I couln't work to half my capacity without it, especially if you are working on an area where you dont know the schema properly

The forthcoming 2008 version is more like visual studio. Just have a look at http://channel9.msdn.com/ShowPost.aspx?PostID=387069

I cannot wait to get my hands on this.

Isshou

vesuvius wrote:
The rant about Linq to SQL is a valid and pertinent one. Yes linq is abstract and passive but no-one is stating the real world problems with using it. That is the problem with being passive. This is the problem when you try things out, you miss the small details that make working with Linq or anything for that matter an absolute headache.

I will give you a few examples.
Try and databind to anonymous types using a winfoms datagrid view and have CRUD and formating of the datagrid view. Ensure that this using modulable patterns and practices. Compare the volume, cleanness, understandability and separation of this code, and lets say, table adapters
Try to databind to custom business objects in another layer
Proceed to use the SetColumnError method using Linq validation and you soon find that you have to write oodles of code

For the first issue, how do you see data binding to anonymous types as a LINQ problem? Quite frankly if you're data binding, maybe you shouldn't be using a shortcut like anonymous types? Especially with all the restrictions placed upon it, wouldn't it be better to have your own class that you can add to rather than an anonymous class made by the compiler sometime down the line?

Again with 2, how is this a LINQ issue, maybe I'm just missing the connection here, but there shouldn't be any difference between a custom business object populated manually and one populated by LINQ. Now if you were wanting CRUD back to a database, then there will always be more steps to take when using an object, regardless of whether LINQ is there or not.

From everything I've seen and read about LINQ, at least currently, is not designed for (two-way?) databinding. There are ways to implement databinding through LINQ, there's even a library produced by a MVP Paul Stovell for performing complete databinding through LINQ: SyncLINQ

To me LINQ seems akin to WCF and the Sync Framework where what is provided doesn't specify everything, if you're dealing with more advanced concepts, propietary data sources, etc you have to write a client or sync endpoint to work with the underlying technology.
This is especially prevelent when you look to see what LINQ to x are out there (SharePoint, Amazon, Entities, etc).

esoteric
λ

vesuvius: It sounds like your problems with LINQ To SQL is with Windows Forms. I don't see the relevance of that as a critique of LINQ!?

littleguru
<3 Seattle

LINQ is just such a bad name for the technique. It should have been named different. All people think it's SQL or something like SQL and for databases. I wonder how long it takes until the last understands that that LINQ can only be used for that but isn't that.

vesuvius
Das Glasperlenspiel

Isshou wrote:

vesuvius wrote:The rant about Linq to SQL is a valid and pertinent one. Yes linq is abstract and passive but no-one is stating the real world problems with using it. That is the problem with being passive. This is the problem when you try things out, you miss the small details that make working with Linq or anything for that matter an absolute headache.

I will give you a few examples.
Try and databind to anonymous types using a winfoms datagrid view and have CRUD and formating of the datagrid view. Ensure that this using modulable patterns and practices. Compare the volume, cleanness, understandability and separation of this code, and lets say, table adapters
Try to databind to custom business objects in another layer
Proceed to use the SetColumnError method using Linq validation and you soon find that you have to write oodles of code

For the first issue, how do you see data binding to anonymous types as a LINQ problem? Quite frankly if you're data binding, maybe you shouldn't be using a shortcut like anonymous types? Especially with all the restrictions placed upon it, wouldn't it be better to have your own class that you can add to rather than an anonymous class made by the compiler sometime down the line?

Again with 2, how is this a LINQ issue, maybe I'm just missing the connection here, but there shouldn't be any difference between a custom business object populated manually and one populated by LINQ. Now if you were wanting CRUD back to a database, then there will always be more steps to take when using an object, regardless of whether LINQ is there or not.

From everything I've seen and read about LINQ, at least currently, is not designed for (two-way?) databinding. There are ways to implement databinding through LINQ, there's even a library produced by a MVP Paul Stovell for performing complete databinding through LINQ: SyncLINQ

To me LINQ seems akin to WCF and the Sync Framework where what is provided doesn't specify everything, if you're dealing with more advanced concepts, propietary data sources, etc you have to write a client or sync endpoint to work with the underlying technology.
This is especially prevelent when you look to see what LINQ to x are out there (SharePoint, Amazon, Entities, etc).

Databinding with Linq and anonymous types is pretty important because in most applications you have related tables, i.e Customers and Orders. You can do this with Linq Projections, Look at Scott Gu's blog http://weblogs.asp.net/scottgu/archive/2007/04/21/new-orcas-language-feature-query-syntax.aspx. You then have to ask youself this. I thought Linq was saving me time as an ORM? I have already gone through the pain point of defining several dozens of projections. You soon find that you have dozens and dozens of classes. If someone other than the person that created the classes has a look at the program it is overly complex. With table adapters it's a matter of a correlated query or Sproc. Linq increases productivity apparently. Please write a sizable applications and report back to this thread.
I like Sync Linq and this point to the lack of support from Microsoft. Paul Stovell has provided a workaround. Unfortunately for me I had had just about with missing features in Linq and went to datasets when this came out.
I should not have to add the type of features I need for Linq to SQL. This is a ubiquitous providor model. My time is better used elsewhere. Linq to SQL will be great next version, it's somewhat lacking at present.

wisemx
Live it

Actually I like the name.
Part of the reason I like LINQ so much is where I started with XML.
In 1999 I spent an entire year writing CDATA and Style code for XML.

Yes it took a few years to get where we are but...
How awesome is it that we can slap out "well" formatted XML so easily. Wink

littleguru
<3 Seattle

Probably you want something that's more the Entity Framework?

vesuvius
Das Glasperlenspiel

esoteric wrote:
vesuvius: It sounds like your problems with LINQ To SQL is with Windows Forms. I don't see the relevance of that as a critique of LINQ!?

No my problem is with Linq to SQL. The architecture I use for my smart clients is the same as for web clients. I started out in Web Development and use the following apotheosis tutorials for windows Forms; http://www.asp.net/learn/data-access/

These tutorials are simply the best that exist (I have worked through most of them). It is of fundamental importance that my Data Acess Layer works against a web or smart client.

If you take some time to trawl through the forums and look for people who are wanting to implement scalable N-Tier web or smart clients, you will get the same response. ASP.NET does have a Linq data source, but the majority of website owners/vendors are still .NET 2.0 (that I know anyway)

vesuvius
Das Glasperlenspiel

littleguru wrote:
Probably you want something that's more the Entity Framework?

Now that will be something but tell me. When was the last time a new technology came out and you used it in a Live project?

This will be an add on to VS, and recent experience means I won't touch it until the next VS version at least.

vesuvius
Das Glasperlenspiel

littleguru wrote:
LINQ is just such a bad name for the technique. It should have been named different. All people think it's SQL or something like SQL and for databases. I wonder how long it takes until the last understands that that LINQ can only be used for that but isn't that.

The more i think about this, the more I agree with you!