LINQ vs. Traditional ADO .NET

[Scott M.]

As I start learning LINQ (and say to myself it's about time they came up
with a simple way to do querying of various data models) I am forced to
wonder, with the new classes in LINQ to SQL in particular, if there is any
performance impact of using things like DataContexts and tables, rather than
the traditional Connection, Command, DataSet classes.

I know that these LINQ classes map to the ADO .NET classes, but is there any
additional overhead to using them?

Also, since Strongly-Typed datasets used to be the way to go as a best
practice, does LINQ (and its table classes) make them obsolete for certain
purposes?

Thanks,

Scott

 

[Cor Ligthert[MVP]]

Scott,

For me the main problem with Linq is that it uses Anonymous classes. For
some people that is a nice word and "It is new so it should be better".

Linq is for me really a greath extention to the languages, but at the end
there is a Q while it has very easy create and update posibilities.

The main problem with a anonymous class is that you can not reference it,
because it is anonymous. That means that you can create all kind of
spaghetti workarounds to make referencable collections (I have seen people
doing this while using non strongly typed code), however put while doing
that in my idea the horse behind the cart.

I see it as an extention, not as a replacement.

Because everything goes today so fast, I am not interested so much any more
in speed, as it is that then use DOA as Bill V often has written.

Be aware that I write this about connected software, I have not yet used
Linq to XML.

Cor

 

[Cor Ligthert [MVP]]

Bill,

I know you did not write DOA.



Cor

Scott,

For me the main problem with Linq is that it uses Anonymous classes. For
some people that is a nice word and "It is new so it should be better".

Linq is for me really a greath extention to the languages, but at the end
there is a Q while it has very easy create and update posibilities.

The main problem with a anonymous class is that you can not reference it,
because it is anonymous. That means that you can create all kind of
spaghetti workarounds to make referencable collections (I have seen people
doing this while using non strongly typed code), however put while doing
that in my idea the horse behind the cart.

I see it as an extention, not as a replacement.

Because everything goes today so fast, I am not interested so much any
more in speed, as it is that then use DOA as Bill V often has written.

Be aware that I write this about connected software, I have not yet used
Linq to XML.

Cor

 

[Miha Markic]

Scott,

For me the main problem with Linq is that it uses Anonymous classes. For
some people that is a nice word and "It is new so it should be better".

It *can* use anonymouss classes. It is perfectly safe to work with normal
classes, nobody is forcing you to use one or the another.

 

[Miha Markic]

Hi Scott,

As I start learning LINQ (and say to myself it's about time they came up
with a simple way to do querying of various data models) I am forced to
wonder, with the new classes in LINQ to SQL in particular, if there is any
performance impact of using things like DataContexts and tables, rather
than the traditional Connection, Command, DataSet classes.

I know that these LINQ classes map to the ADO .NET classes, but is there
any additional overhead to using them?

Talking about LINQ to SQL and any other ORM out there: yes, there is, but
usually the benefits outweight it.

Also, since Strongly-Typed datasets used to be the way to go as a best
practice, does LINQ (and its table classes) make them obsolete for certain
purposes?

Oh yes.

 

[Cowboy \(Gregory A. Beamer\)]

It is not forced to use anonymous classes. On the other side, when LINQ is
used as planned, I do not see these anonymous classes as a problem.

We also have to remember that LINQ is not an ORM in the traditional sense.
It is also not a great replacement for all of your data access needs. It has
been sold that way, but it falls flat in many applications, so you have to
fit the round peg in the round hole and the square peg in the square hole.

To put this into a real situation, wiring the anonymous classes to kludges
so you can use LINQ is a sure sign you are searching for nails with your
LINQ hammer. In short, if you find yourself kludging things, you are using
the wrong tool. I have seen the code and I think it is really creative, but
it is both a) not using LINQ correctly and/or b) using LINQ when another
tool would work better.

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

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

or just read it:
http://gregorybeamer.spaces.live.com/

********************************************
| Think outside the box! |
********************************************

 

[Cor Ligthert[MVP]]

Gregory,

Did I write something else, I had not that idea myself?

Cor

 

[Cowboy \(Gregory A. Beamer\)]

Sorry Cor. I had the newsgroups open for hours before I answered and did not
refresh. The bane of Outlook Express?

Will try to remember to refresh when I get sidetracked to ensure I am not
duping answers.

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

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

or just read it:
http://gregorybeamer.spaces.live.com/

********************************************
| Think outside the box! |
********************************************

 

[Cowboy \(Gregory A. Beamer\)]

Ignore the last post.

I was thinking of another instance. My mind is shot today. Time to take
lunch and give it a rest.

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

Subscribe to my blog
http://gregorybeamer.spaces.live.com/lists/feed.rss

or just read it:
http://gregorybeamer.spaces.live.com/

********************************************
| Think outside the box! |
********************************************