What parts of LINQ should we learn?

[Justin Dutoit]

Hey folks. After some Googling and reading, it's not clear to an
intermediate coder like me whether LINQtoSQL or LINQtoEntities will be
around in the long term. Some pretty capable people seem to disagree about
whether they are good or bad. What I need is for some experienced folks to
share which *parts* of e.g. LINQtoSQL I should learn. Surely there are parts
of it that are right already and won't change significantly. So please
advise what you think we should learn, and how to prepare for the future in
this area.

Cheers,
Justin Dutoit

 

[Mr. Arnold]

Hey folks. After some Googling and reading, it's not clear to an
intermediate coder like me whether LINQtoSQL or LINQtoEntities will be
around in the long term. Some pretty capable people seem to disagree about
whether they are good or bad. What I need is for some experienced folks to
share which *parts* of e.g. LINQtoSQL I should learn. Surely there are
parts of it that are right already and won't change significantly. So
please advise what you think we should learn, and how to prepare for the
future in this area.

MS is not going to support LINQ-to-SQL like it will with the ADO.NET Entity
Framework from what I understand. The Entity Framework is an ORM solution
and LINQ-to-SQL is not an ORM solution.

<http://blogs.msdn.com/adonet/archiv...linq-to-sql-and-linq-to-entities-roadmap.aspx>

Also, an ADO.NET Entity Framework Entity is an implicit datacontract to a
WCF service.

http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework

http://en.wikipedia.org/wiki/Object-relational_mapping

The book has Linq-to-SQL and the ADO.Net Entity Framework.

<http://www.free-ebooks-download.org...-language-integrated-query-in-csharp-2008.php>

 

[Cowboy \(Gregory A Beamer\)]

In the current implementation, the Entity Framework may work well with WCF,
but it is a problematic framework when you are working with WCF SOAP
services that talk to other languages, like Java. I posted the issue here:
http://gregorybeamer.spaces.live.com/blog/cns!B036196EAF9B34A8!806.entry

MS is not going to support LINQ-to-SQL like it will with the ADO.NET
Entity Framework from what I understand. The Entity Framework is an ORM
solution and LINQ-to-SQL is not an ORM solution.

<http://blogs.msdn.com/adonet/archiv...linq-to-sql-and-linq-to-entities-roadmap.aspx>

The Visual Studio 2010 CTP still shows heavy usage of LINQ story. While MS
is certainly pushing the Entity Framework story heavily, as it is an O/R
Mapper technology, there is a heavy investment in LINQ and I do not see LINQ
to SQL going away. Whether or not it continues to be "downplayed" will be
determined by developers around the world.

Also, an ADO.NET Entity Framework Entity is an implicit datacontract to a
WCF service.

http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework

http://en.wikipedia.org/wiki/Object-relational_mapping

This is wonderful as long as you are talking Microsoft to Microsoft.
http://gregorybeamer.spaces.live.com/blog/cns!B036196EAF9B34A8!806.entry

The Entity Framework handles relationships as a separate object. I
understand the reasoning (primarily to have a single object that can use
multiple field joins as easily as a single field join), but having a Java
developer create a join object just to get foreign key fields is overkill.
If enough people design WCF SOAP services for consumption both in and out of
the Microsoft world, I think you will find additional "bitching" over this
feature.

This is not a knock on the Entity Framework. I think the guys did great
work.

The book has Linq-to-SQL and the ADO.Net Entity Framework.

<http://www.free-ebooks-download.org...-language-integrated-query-in-csharp-2008.php>

I am sure Joseph Rattz is overjoyed at Internet piracy. ;-)

 

[Cowboy \(Gregory A Beamer\)]

As long as bottom up development is one of the norms, LINQ to SQL will have
a place. What I mean by this is developers who develop the database, then
the middle tier, then the UI. It will also likely be fine with top down
development (UI >> business >> data), as many top down developers think in
terms of database objects. If we move heavily towards Domain Driven Design,
LINQ to SQL may be less in demand.

You also see the LINQ to SQL story sold heavily by the ASP.NET team,
especially in the MVC implementation. As much of the Microsoft user
experience is in the web space, I would watch what they are pushing prior to
selling LINQ short.

If you want the shortest learning curve, get a copy of LINQPad. It is free.
Use it as your "query analyzer" on your database. It forces you to think
your queries in LINQ and after a week, you will be fairly proficient or you
will scrap the idea. Moving from one LINQ subset (LINQ to SQL) to another
(LINQ to Entities) is fairly easy. There is not much in one that is not in
the other.

Just my two cents.

 

[Cowboy \(Gregory A Beamer\)]

LINQPad is extremely useful.


LOL! That's so true! In my experience with mentoring clients on LINQ, they
either love it or hate it...

Most appreciate straightaway the ability to "query" virtually any .NET
object collection using syntax which is very similar to SQL, but some find
more difficulty in seeing the point of / need for LINQ to SQL...

Some see it as backwards SQL. Of course, the backwards nature is why you get
full intellisense and why intellisense for SQL does not work extremely well.

 

[Mr. Arnold]

In the current implementation, the Entity Framework may work well with
WCF, but it is a problematic framework when you are working with WCF SOAP
services that talk to other languages, like Java. I posted the issue here:
http://gregorybeamer.spaces.live.com/blog/cns!B036196EAF9B34A8!806.entry

However, ADO.NET Entity Framework and WCF Web service in conjunction with
n-tier SOA is fabulous. Unlike Nhibernate where you have to use a DAO and a
DTO to move serialized data between the tiers using a Web service, one can
just use/get the entity at the BLL as an object from the WCF Web service
interface, send the entity back to the DAL via the WCF Web service interface
and persist the entity to the model, because it is an implicit datacontract.

In other words, I have access to all properties of the entity at the BLL as
a WCF Web service client , and I can get it or send it back via a WCF Web
service interface and let the DAL object act upon the methods and or
properties of the entity.

If I was concerned about using WCF SOAP with something like Java, then I
would be using a DAO and DTO implementation. IMHO, the power of the ADO.NET
Entity Framework is apparent in a .NET n-tier WCF solution with the Model
sitting on the back-end.