LINQ and Entity Framework - Worth a stab?

[Cirene]

I'm about to begin a brand new, big, ASP.NET project (using 3.5 .net fw), VS
2008. I'm using MySQL as the backend (customer request.) I have absolutely
no experience with LINQ and/or the Entity Framework. Though I am quite
comfortable with ADO.NET and VB.NET.

In your opinion, should I take a few days and learn it and utilize these
technologies in this new project (I'm starting from scratch)? Are the
benefits worth it in your opinion? Is there a steep learning curve in your
opinion? Or should I stick with what I know for this project?

I value Your opinion, so please let me know...

 

[Cirene]

IMO, one of the worst things that a developer can do is to take a new
piece of technology and then go looking for a problem for it to solve...

I would suggest that you take a few days and learn LINQ, but utilise it
ONLY IF IT IS APPROPRIATE for the project. It might be, it might not be...

Thanks for your input. I was thinking that "biting the bullet" and learning
it will (1) keep me on the cutting edge technically and (2) take advantage
of the new benefits. Thanks again...

 

[Andy B]

What kind of projects is linq good for then? and What kind of projects is it
not good for... can you give some examples of each?

 

[Andy B]

[please don't top-post]

What kind of projects is LINQ good for then? and What kind of projects is
it not good for... can you give some examples of each?

LINQ is a set of extensions to the .NET Framework which encompass
language-integrated query, set, and transform operations. It extends .NET
languages with native language syntax for queries and provides class
libraries to take advantage of these capabilities.

Put simplistically, LINQ allows .NET collection objects to be queried with
syntax which resembles T-SQL. If your project has a requirement to query
collection objects, and you would like to do that with syntax which
resembles T-SQL, the LINQ will be be perfect for your project. If your
project has no need to do this, then LINQ will be of no use to you.

Take AJAX as an example. AJAX is great for allowing parts of web pages to
be updated from the server without needing to refresh the entire page -
callbacks instead of postbacks. However, if you have no need to refresh
parts of web pages without needing to refresh the entire page, and you're
perfectly happy with good ol' postbacks, then AJAX is of no use to you. So
don't use it - you don't have to if you don't want to or need to...

Similarly, the ASP.NET ValidationControls. What are they good for? They
are good for projects which need validation. Projects which don't need
validation have no use for the ValidationControls. Alternatively, some
developers (like me) have evaluated the ValidationControls and find them
to be too restrictive so we don't use them.

Ok, I use sql server databases all the time. It's is the entire backbone of
the web applications I am working on now. What would you feel about using
linq to sql in this case?

 

[bruce barker]

it depends on requirements. linq has two modes:

one where its a query of collections (its as efficient as any code you
write). you should learn linq to replace your for loops as the code will
run faster (especially if you use foreach).

the other is where it generates an expression tree (at compile time),
that is converted to code at runtime. this is how linq to sql works. the
expression tree is converted to dynamic sql and executed. its great for
data binding but less useful if you use stored procedures for all you
sql access.

the entity framework can be used with or without linq. if you business
objects are really just based on tables and not a logical view, then
entity framework is great. it will build a class for each table and
supports relationships to other tables. its considerable better than
typed datasets.

-- bruce (sqlwork.com)

[please don't top-post]

Thanks for your input. I was thinking that "biting the bullet" and
learning it will (1) keep me on the cutting edge technically and (2)
take advantage of the new benefits. Thanks again...
Learning LINQ (just like learning any new technology) will indeed keep
you up to date, but it's really important not to let technology drive
the solution... Just because a piece of technology is new and exciting
doesn't mean that it's always the appropriate thing to use in every
situation...
What kind of projects is LINQ good for then? and What kind of projects is
it not good for... can you give some examples of each?

LINQ is a set of extensions to the .NET Framework which encompass
language-integrated query, set, and transform operations. It extends .NET
languages with native language syntax for queries and provides class
libraries to take advantage of these capabilities.

Put simplistically, LINQ allows .NET collection objects to be queried with
syntax which resembles T-SQL. If your project has a requirement to query
collection objects, and you would like to do that with syntax which
resembles T-SQL, the LINQ will be be perfect for your project. If your
project has no need to do this, then LINQ will be of no use to you.

Take AJAX as an example. AJAX is great for allowing parts of web pages to
be updated from the server without needing to refresh the entire page -
callbacks instead of postbacks. However, if you have no need to refresh
parts of web pages without needing to refresh the entire page, and you're
perfectly happy with good ol' postbacks, then AJAX is of no use to you. So
don't use it - you don't have to if you don't want to or need to...

Similarly, the ASP.NET ValidationControls. What are they good for? They
are good for projects which need validation. Projects which don't need
validation have no use for the ValidationControls. Alternatively, some
developers (like me) have evaluated the ValidationControls and find them
to be too restrictive so we don't use them.

Ok, I use sql server databases all the time. It's is the entire backbone of
the web applications I am working on now. What would you feel about using
linq to sql in this case?

 

[Cowboy \(Gregory A. Beamer\)]

ANy time you throw a non-Microsoft technology into the mix, you increase
your programming time. As such, it is better to stick with technologies that
have been out awhile, where you can find pages to help you through the
configuration and coding.

I also agree with Mark that running around with a hammer, looking for nails,
is not a good way to solve a problem.

 

[Cowboy \(Gregory A. Beamer\)]

ANy time you throw a non-Microsoft technology into the mix, you increase
your programming time. As such, it is better to stick with technologies that
have been out awhile, where you can find pages to help you through the
configuration and coding.

I also agree with Mark that running around with a hammer, looking for nails,
is not a good way to solve a problem.