What do you think of LINQ? Looks like not intended to be used with WCF so what architecture do you

[Ronald S. Cook]

Sorry if this is the wrong forum, but wondering what you guys think about
LINQ.

We were architecting our enterprise Win app as WCF for the benefits of:

- single place for business tier
- thin client

But those aren't incredibly strong arguments, since 1) ClickOnce makes
client deployments easy, and 2) hard disk space is cheap. (Ours isn't a web
app so we don't need the HTTP benefit of WCF which to me would be the
biggest).

So LINQ looks great for several reasons, but doesn't seem to play well with
WCF.

QUESTIONS:

1) Do you find yourself looking at LINQ instead of WCF or to be used in
conjunction with?
2) Are you considering LINQ to SQL or LINQ to Entities and why one or the
other?

Thanks for any general comments. I'm just looking to see what you guys are
all thinking about this.

Ron

 

[Christof Nordiek]

Sorry if this is the wrong forum, but wondering what you guys think about
LINQ.

We were architecting our enterprise Win app as WCF for the benefits of:

- single place for business tier
- thin client

But those aren't incredibly strong arguments, since 1) ClickOnce makes
client deployments easy, and 2) hard disk space is cheap. (Ours isn't a
web app so we don't need the HTTP benefit of WCF which to me would be the
biggest).

There are othe reasons for back tier applications, like enforcing
businessrules in one place.

So LINQ looks great for several reasons, but doesn't seem to play well
with WCF.

Why do you say, LINQ doesn't play well with WCF. Couldn't find that in your
post.
I don't think LINQ should occur in the presentation layer, but in the BL or
the BL/DL - boundery.

QUESTIONS:

1) Do you find yourself looking at LINQ instead of WCF or to be used in
conjunction with?

I don't think, one replaces the other. They play in different places.

 

[Nicholas Paldino [.NET/C# MVP]]

Ronald,

I don't think that WCF and LINQ are mutually exclusive. LINQ in
intended to simplify the querying of data in various forms through language
constructs/libraries while WCF is intended to help with providing the
plumbing required for distributed applications.

There is no reason why a WCF service can't serve up strongly-typed data
to a client, and then the client can't use LINQ to manipulate that data.
Also, there is no reason why the WCF service can't use LINQ to put together
the data to serve back to the client.

As for whether I'm considering LINQ to SQL or LINQ to Entities, I don't
know that I am going to use either right now, although my interest is more
in the LINQ to Entities, as it seems to provide more control, and more
options (with of course, a steeper learning curve). Personally, I see the
technologies as being competitive, which I don't like to see from a single
vendor. There is a ton of overlap between the two, and my hope is that MS
cleans up this situation sooner than later.

 

[Nicholas Paldino [.NET/C# MVP]]

I think that specifically, you mean that LINQ to SQL shouldn't occur in
the presentation layer. However, I don't see why LINQ to Objects shouldn't
be used. Certainly, there is a need for querying objects in the
presentation layer, and LINQ to Objects could certainly help there.

 

[Jon Skeet [C# MVP]]

Sorry if this is the wrong forum, but wondering what you guys think about
LINQ.

I think it's going to be fantastic. However:

1) Don't think that LINQ = LINQ to SQL. I fully expect to use LINQ to
Objects more than LINQ against any databases.

2) Don't think that LINQ to SQL (or LINQ to Entities) = 2 tier
architecture. People have been using ORMs for ages in n-tier solutions
- there's no reason why you shouldn't use LINQ to SQL in the business
layer, then use LINQ to Objects in the presentation layer.

 

[Alun Harford]

Sorry if this is the wrong forum, but wondering what you guys think about
LINQ.

We were architecting our enterprise Win app as WCF for the benefits of:

- single place for business tier
- thin client

But those aren't incredibly strong arguments, since 1) ClickOnce makes
client deployments easy, and 2) hard disk space is cheap. (Ours isn't a web
app so we don't need the HTTP benefit of WCF which to me would be the
biggest).

So LINQ looks great for several reasons, but doesn't seem to play well with
WCF.

QUESTIONS:

1) Do you find yourself looking at LINQ instead of WCF or to be used in
conjunction with?
2) Are you considering LINQ to SQL or LINQ to Entities and why one or the
other?

Thanks for any general comments. I'm just looking to see what you guys are
all thinking about this.

I'm yet to use the LINQ syntax seriously.

It looks like somebody was told to implement SQL-like syntax in C#, and
they didn't really want to do that. SQL is a nasty language that we're
forced to use - not one we should base a new language feature on, so
they did it properly, and then added the SQL-like rubbish as a
'convenience'.

Which would you prefer, as a C# programmer:

result = someCollection.Where(a=>a.Foo).Select(a=>a.SomeProperty);

or

result = select a.SomeProperty from someCollection where a.Foo;


From what I've seen of LINQ-to-entities and LINQ-to-SQL, I'm
unconvinced that it's a better solution than something like Castle
ActiveRecord.

The only thing LINQ-to-Entities seems to have going for it is the
ability to query the database with a nicer syntax (the functional syntax
- not the horrible SQL-like thing), but I expect that ActiveRecord (and
pretty much every ORM out there) will have that before LINQ-to-Entities
is launched.

Alun Harford

 

[Jon Skeet [C# MVP]]

I'm yet to use the LINQ syntax seriously.

I think that goes for most of us.

It looks like somebody was told to implement SQL-like syntax in C#, and
they didn't really want to do that. SQL is a nasty language that we're
forced to use - not one we should base a new language feature on, so
they did it properly, and then added the SQL-like rubbish as a
'convenience'.

Which would you prefer, as a C# programmer:

result = someCollection.Where(a=>a.Foo).Select(a=>a.SomeProperty);

or

result = select a.SomeProperty from someCollection where a.Foo;

Well, I would prefer:

result = from item in someCollection
where item.Foo
select item.SomeProperty;

It expresses the same thing (but in valid C# 3!) without as much
repetition in the lambda expressions.

But yes, it's perfectly reasonable to use the extension methods
directly for simple cases. It gets worse when you've got joins,
multiple filters, ordering etc.

From what I've seen of LINQ-to-entities and LINQ-to-SQL, I'm
unconvinced that it's a better solution than something like Castle
ActiveRecord.

Do you not like having compile time validation of queries?

The only thing LINQ-to-Entities seems to have going for it is the
ability to query the database with a nicer syntax (the functional syntax
- not the horrible SQL-like thing), but I expect that ActiveRecord (and
pretty much every ORM out there) will have that before LINQ-to-Entities
is launched.

I'm sure every serious ORM will pick up LINQ - but it would be foolish
of MS not to have their own fully fledged one too. In addition, anyone
picking up the general EDM strategy will benefit from LINQ to Entities.

 

[Keith P]

The use that comes to mind when I think of LINQ benefits is the ease at with
PLINQ is used...enables nearly automatic threading that is optimized by the
provider via the query structure as opposed to explicity threading/locking
constructs.