Will You Use LINQ?

  • Thread starter Thread starter Jonathan Wood
  • Start date Start date
J

Jonathan Wood

So, VS2008 is now available (http://www.asp.net/). One thing I'm now
wondering about is how much sense LINQ makes.

I've been reading of all the advantages of stored procedures: more secure,
more efficient, and better organization of code associated with a database.
To the extent that's true, it would seem better to avoid LINQ in favor of
stored procedures.

I'd be curious to hear others' take on this.
 
Miha,
LINQ is a language thing. So I assume you are talking about LINQ to SQL
which is an ORM product using LINQ.
Click to expand...

Actually, I was talking about LINQ in Microsoft languages such as C#. (Which
is why I mentioned the release of VS2008, which includes support for this.)
No, I won't be using LINQ to SQL for anything serious, but not because of
stored procedures (which might be used nicely by LINQ to SQL)
Click to expand...

We may be talking about different things--I'm not sure. In the case of LINQ
in C#, it would be replacing statements that could otherwise be in a stored
procedure. I'm just wondering if that's a factor for anyone else.
but because of these reasons:
http://cs.rthand.com/blogs/blog_with_righthand/archive/2007/10/06/LINQ-to-SQL-showstoppers.aspx
Click to expand...

Sheesh! Would it be possible for that guy to have any more typing errors? At
any rate, I have no idea what ORM is and I didn't really understand most of
what he was saying. There's a slight possibility that item 6 and maybe item
2 might be related to the issue that I've raised.

Thanks.
 
Have not determined it yet.

The examples on the market are good at abstracting the query from the data
access, but I can do the same with a factory pattern and have a nice n-tier
setup. I like LINQ, in theory, but I am not sure how I can adapt it to fit
the multi-tiered structures. And the bits I have seen showing how to use
LINQ tend to mush the lines, which means I will have to adapt my design
methodologies, compromise, flatten my design (probably not going to happen)
or scrap LINQ.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************
| Think outside the box!
|
*************************************************
 
Miha is not a native English speaker, so give him some slack on his English
diction. :-)

An ORM is an Object Relational Mapper. It takes relational data, like a SQL
Server table, and maps it to objects. That is basically what LINQ does,
although I would not call it a true ORM.

Where I believe LINQ shows promise is in the abstraction of the actual data
store. In theory, you can write a query once and run it against XML, or SQL,
or a variety of other sources. In practice, it is a bit more difficult than
the marketing material, but this will improve.

It also is very ORM like, as it creates objects from your data, but it is
not what you find in traditional ORM products.

Whether or not it makes sense to use it depends on your applications. If you
are working internal applications and your company is fairly set on
platform, you can probably wait. If you sell products that talk to a variety
of stores, it might make sense. If you are not currently using business
objects, LINQ can help.

The downside Miha mentions in his blog post (n-tiers in specific) is
partially a problem with the samples out there, as I believe one could
design a decent enough n-tier structure around LINQ. I will agree, however,
that the tools are far behind the technology. That is fairly typical of MS.

Should you try LINQ? Sure. It is fun to play around with, if nothing else.
And, you will likely learn some new things about programming, even if you do
not adopt LINQ. If you take it deep enough to learn Lambda expressions, it
is probably worth the trip, especially considering the likelihood the C#
team will expand in the offering in the next version (a guess, but a good
one).

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************
| Think outside the box!
|
*************************************************
 
Jonathan Wood said:
Miha,


Actually, I was talking about LINQ in Microsoft languages such as C#.
(Which is why I mentioned the release of VS2008, which includes support
for this.)
Click to expand...

LINQ is not database related in any way. ORM is. You are actually asking
whether to use an ORM or not to use it.
LINQ is used for all sort of queries thus you can't say should I use LINQ or
stored procedures.
We may be talking about different things--I'm not sure. In the case of
LINQ in C#, it would be replacing statements that could otherwise be in a
stored procedure.
Click to expand...

Only when you are using LINQ to SQL or forthcomming Entity Framework (or any
3rd party ORM that features LINQ).

I'm just wondering if that's a factor for anyone else.
Sheesh! Would it be possible for that guy to have any more typing errors?
Click to expand...

Shees, that guy...I'll tell him.

At
any rate, I have no idea what ORM is and I didn't really understand most
of what he was saying. There's a slight possibility that item 6 and maybe
item 2 might be related to the issue that I've raised.
Click to expand...

Items 2 and 6 are not related. 2 talks about n-tier (sending entities
between application domains) while 6 talks about executing database
operations directly on database (i.e. UPDATE Customer SET Discount =
Discount + 10) without need to load entity-modify it-save-it.
 
Miha,
LINQ is not database related in any way. ORM is. You are actually asking
whether to use an ORM or not to use it.
Click to expand...

As stated in my previous post, I don't even know what ORM is. And, after
your reply, I still do not. Nor am I clear on "LINQ to SQL." I really don't
know what you are talking about.

LINQ is a form of SQL syntax that is used directly in a programming
language. If you place SQL directly in your source code, then you are not
placing it in a stored procedure. I don't get why you seem to resist that.
Shees, that guy...I'll tell him.
Click to expand...

Sorry, didn't realize it was you. You really should proof read more though.
 
Jonathan,

You have asked a question in a subject and then have put text in the message
that did not fit to each other. While in the message was:
stored procedures.

You did not get an answer on the first question in the subject, because it
is an impossible to answer question. Maybe can you ask in future to
somebody. "Who did use LINQ?".

You got your answers on the second question, therefore don't blaim Miha with
what he wrote, your question in the subject is simple impossible to be
answered.

It is as a pot who calls a kettle black.

Cor
 
Jonathan Wood said:
Miha,


As stated in my previous post, I don't even know what ORM is. And, after
your reply, I still do not. Nor am I clear on "LINQ to SQL." I really
don't know what you are talking about.
Click to expand...

Perhaps you should read definition from wikipedia
http://en.wikipedia.org/wiki/Object-relational_mapping
In short, ORM is a technique that maps database entities to objects that
exist in programming world. IOW you operate with objects while ORM takes
care of database interaction for you.
Some ORM products out there:
LLBLGenPro
NHibernate,
WilsonORMapper
LINQ to SQL,
Entitiy Framework (next year probably)
....

While LINQ is a tecnique for querying everything that supports LINQ queries.
LINQ by itself doesn't know what to do with databases. OTOH LINQ to SQL uses
LINQ constructs to generate SQL queries.
So when dealing with databases using LINQ you need an ORM product which
knows how to transform LINQ queries into SQL queries.
About the products listed above: some of them already support LINQ and some
of them will soon support it (they have other way of expressing queries) -
I think that no ORM will ignore LINQ.
Hope this explanation clears the fog a bit.
LINQ is a form of SQL syntax that is used directly in a programming
language. If you place SQL directly in your source code, then you are not
placing it in a stored procedure. I don't get why you seem to resist that.
Click to expand...

Definitely not. As explained above, LINQ is in no way connected to SQL. ORM
(think LINQ to SQL) does the transformatino for you.
Furthermore LINQ to SQL is capable of using stored procedures, so you can
have both. And also, you could embed LINQ to SQL into managed stored
procedures.
 
Are you suffering from some sort of mental disorder or something?

Who's blaming Miha for anything? I requested comments, and he gave some. And
I'm just commenting back.

You have some sort of problem with that?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
 
Miha,
Perhaps you should read definition from wikipedia
http://en.wikipedia.org/wiki/Object-relational_mapping
Click to expand...

It would've been quite difficult for me to do that not knowing what ORM
stood for.
In short, ORM is a technique that maps database entities to objects that
exist in programming world. IOW you operate with objects while ORM takes
care of database interaction for you.
Some ORM products out there:
LLBLGenPro
NHibernate,
WilsonORMapper
LINQ to SQL,
Entitiy Framework (next year probably)
Click to expand...

And so what is the "ORM" product involved in the latest .NET languages?

I want to be clear: All I've seen was a short video showing the new LINQ
feature of VS2008 and C#. I thought I understood what it was. Perhaps I
didn't.

What it looked like was a way to duplicate SQL logic in the language proper.
It seemed logical to conclude that any SQL logic placed within C#, for
example, would therefore not be placed in a stored procedure, because a
stored procedure would not be in C#. I'm still not clear where the flaw in
that logic, if any, lies.
While LINQ is a tecnique for querying everything that supports LINQ
queries.
LINQ by itself doesn't know what to do with databases. OTOH LINQ to SQL
uses LINQ constructs to generate SQL queries.
So when dealing with databases using LINQ you need an ORM product which
knows how to transform LINQ queries into SQL queries.
About the products listed above: some of them already support LINQ and
some of them will soon support it (they have other way of expressing
queries) - I think that no ORM will ignore LINQ.
Hope this explanation clears the fog a bit.
Click to expand...

I guess I figured that by specifically referring to the LINQ in the latest
version of .NET languages, I was being far more specific than the
description above.
Definitely not. As explained above, LINQ is in no way connected to SQL.
ORM (think LINQ to SQL) does the transformatino for you.
Furthermore LINQ to SQL is capable of using stored procedures, so you can
have both. And also, you could embed LINQ to SQL into managed stored
procedures.
Click to expand...

<shrug> I guess I'll need to do some more reading on LINQ in .NET.

Thanks.
 
Are you suffering from some sort of mental disorder or something?

Who's blaming Miha for anything? I requested comments, and he gave some.
And I'm just commenting back.

You have some sort of problem with that?
Click to expand...

In the way you did it, Yes.

I am not the biggest friend with Miha, but the way you think that you are
allowed to act is realy disguisting.

People like you will make that people stop helping others.

Cor
 
I have absolutely no idea what the heck you are rambling on about. Anything
you interpreted as blaiming Miha is based on your misunderstanding (except
for maybe his typing errors on his site). Miha didn't seem to have a problem
with what I said. Although I didn't understand all that he said, I still the
discussion was useful, for me anyway.

So why don't you just go and mind your own business?

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
 
Cowboy,
Miha is not a native English speaker, so give him some slack on his
English diction. :-)
Click to expand...

Okay, well, I didn't initially realize it was his writing I criticized. And
he looked English from his picture. So my apologies to Miha.
The downside Miha mentions in his blog post (n-tiers in specific) is
partially a problem with the samples out there, as I believe one could
design a decent enough n-tier structure around LINQ. I will agree,
however, that the tools are far behind the technology. That is fairly
typical of MS.
Click to expand...

I must confess I had trouble understanding him, perhaps in part due to my
lack of knowledge on the subject. But you seem to be describing the exact
same problem I was trying to describe in my initial post. While I focused on
stored procedures, I guess n-tier is the issue I was trying to address.

Above, you seem to be referring to the fact that you could put LINQ code in
your data layer. But that still leaves stored procedures, which I'm
understanding can be more efficient and secure than SQL queries from code.
So I was looking at this as a problem with using LINQ. But, clearly, I need
a better understanding of the subject.

Thanks.
 
Jonathan Wood said:
Cowboy,


Okay, well, I didn't initially realize it was his writing I criticized.
And he looked English from his picture.
Click to expand...

LOL. Now I'll try to figure out whether this is a compliment or not :-)
So my apologies to Miha.
Click to expand...

Hey, no problem, I know my english is not perfect - feedback appreciated.
 
I won't use it much for DB querying, as there's already DataSourceControls
and stored proc calls for that (although I'd still use LINQ to C# to interact
with them when I have them in memory). Where I'll definitely migrate is in
code itself...loops primarily. I tend to do a decent # of nested loops with
IFs for filtering, and LINQ very nicely abstracts this out. It's a radical
departure from the standard procedural FOR(EACH)/IF...ELSE/etc but the nice
thing is that it's a higher level abstraction that lends itself very well to
threaded code (the ParallelFX library's provider: PLINQ, specifically) nearly
automatically (you add .AsParallel() to an IEnumerable, and the provider will
automatically optimize the resulting expression tree to a threaded routine
that is optimized on the fly for your environment.
 
Back
Top