It's been uncharacteristically quiet on the LINQ front since Scott Guthrie announced that VS 2008 Beta 2 was due by the end of the month. Most LINQ aficianados have been waiting for the Beta 2 bits to drop. But there were a few items worth covering this week, to wit:
Scott Guthrie Demos the ASP.NET LINQDataSource Control
Scott's lengthy LINQ to SQL (Part 5 - Binding UI using the ASP:LinqDataSource Control) is the latest in his detailed demonstrations of LINQ to SQL in WebForms. Like almost all other code examples provided by the VS teams in the past two months, this episode requires VS 2008 Beta 2. (The Orcas June 2007 CTP doesn't include the LINQDataSource control, formerly named the LinqDataSource control.)
- Displaying human-readable names for numeric foreign key values requires two SQL queries per row if lazy loading is used.
- The LINQDataSource control is tied to LINQ to SQL and won't interoperate with third-party O/RM tools that implement "generic" LINQ features.
- Grouping entities makes them read-only (Comment: Grouping data rows makes them read-only, too).
- Strings "inside the eval calls" are brittle and will make the page "fall apart at runtime."
Scott sets the record straight in this reply comment of the same date:
- Eager loading (pre-fetching) is a LINQ to SQL option that you implement with the Span property. Scott will cover this in a future post.
- The LINQ DataSource will support for additional O/RM tools "in the future." First on tap will be LINQ to Entities (which is running now as a prototype) and the ASP.NET team will release the source code. Scott says (with tongue in cheek?), "It would obviously be great to get support for it with additional OR/M's like LLBLGen."
- If the data has been made read-only by a grouping operation, the UI provides visual clues.
- An alternative to Eval is to use code-behind to set values.
Scott confirmed in this reply comment that "VS 2008 and .NET 3.5 Beta2 should be available for download in a little over a week."
Here are links to the preceding four episodes:
- Part 1: Introduction to LINQ to SQL
- Part 2: Defining our Data Model Classes
- Part 3: Querying our Database
- Part 4: Updating our Database
Bart DeSmet Frees SharePoint Developers from CAML Coding
Bart's worked hard for the past three weeks to get the latest update to LINQ to SharePoint ready to test before his move from Belgium to Redmond this fall. He's just posted the Alpha 0.2.2.0 version to his CodePlex site.
His new installer for the LINQ to SharePoint binaries is set up for Orcas Beta 1 and might not work with Orcas June 2007 CTP or VS 2008 Beta 1. If I have the time, I'll test it with the CTP. The 0.2.2 Alpha Interim Overview post (above) includes fully illustrated installation instructions.
Another interim release, likely 0.2.3 and planned for mid August, will cover:
- List attachments
- Additions to SPML and SpMetal improvements (generate SPML, consume SPML) + improvements for the entity wizard
- Grouping support (under investigation)
- Support for User fields (under investigation)
Erik Meijer Gives Yet Another LINQ Lecture on Channel9
VB evangelist Beth Massi tapped Erik Meijer for a 37-minute Erik Meijer Shows Us His Favorite Visual Basic 9.0 Feature - XML Literals interview. Here's Beth's description of the coverage:
In this interview Erik Meijer, an Architect on the Data Programmability team, shows us how LINQ to XML works in the next version of Visual Basic, 9.0. He talks about some of the history behind the features as well as how XML literals, unique to Visual Basic, are implemented. He takes us on an adventure on how to efficiently work with XML using XML IntelliSense and an Office Open XML Excel document, pointing out a lot of tidbits of information along the way that only Erik could show us.
Implementing a Many-to-Many Relationship in LINQ to SQL
Mitsuru ("Mitsu") Furuta, a developer evangelist for Microsoft France, has written sample code for creating many-to-many associations between LINQ to SQL EntitySet objects. The lack of support for direct one-to-many associations (without relation tables, such as Northwind's Order_Details table) has disappointed many potential users of LINQ to SQL, the Entity Framework and LINQ to Entities.
Using Mitsu's proxy class approach that's described in his How to implement a many-to-many relationship using Linq to Sql? post, you can write:
foreach (Product p in order.Products) ... ;
foreach (Order_Detail od in order.Order_Details)
Product p = od.Product ... ;
Mitsu's C# sample code runs under Orcas Beta 1 and includes IList and IBindingList implementations for data binding.
Slightly Off-Topic: A Strange Proposal to Ease VB Developers' C# Envy
Paul Vick's 7/20/2007 lowercase keywords? post wonders "how much the fact that we uppercase [VB] keywords affects our perception?" Of course, the question is "Perception of what?" His post starts with:
One of the raps that VB sometimes gets is that we're too "verbose."
In general, I prefer VB's verbosity to C# tersity by symbology. However, this preference declined dramatically when having to write .Where(Function(ByVal c) c.Country = "USA") instead of .Where(c => c.Country == "USA") or the like a few hundred times. On the whole, I prefer C# syntax for lambda expressions.
I believe what Paul meant by "our perception" is "our perception [of VB as a second-class language]" because his post implies that changing from VB's Pascal-case (proper-case) to lower case keywords will deliver a dose of (imagined) C# cachet to the Visual Basic language. Implicit in this misunderstanding is that typing lower-case keywords will infuse VB developers with the (imagined) élan of C# programmers.
I believe that VB has acquired the second-class language stigma as the result of Microsoft's developers writing 100% C# unless instructed or paid to do otherwise. (A possible exception is Erik Meijer, who's an architect not a developer.)
Another Microsoft contribution to the perception of VB's inferiority to C# is late adoption or omission of new C# language features. For example, VB's support for lambda expressions and the LINQ aggregate (Sum, Min, Max, etc.), Group By, Group Join, Join, Let, Skip [While] and Take [While] keywords didn't arrive until the Orcas June 2007 CTP but they were present in C# during 2006's LINQ CTPs.
Another factor is lack of sufficient resources devoted to VB in Visual Studio 2008. According to Paul's June 27, 2007 What's in VB 2008? What's out? post:
For VB 2008, we will only support initializing read-write fields of non-collection objects [... and] only support expressions in lambdas, not statements.
Our original plans, going back to PDC05, included several more features for object initializers, such as being able to write to read-only properties, as well as collection and array initializers. In the end, the schedule for VS 2008 was not sufficient to implement these features with a high degree of confidence. Which unfortunately means that they will have to wait to a release beyond VS 2008.
Finally, C# bigotry by some .NET developers and writers contributes to VB programmers' perception of language inferiority. For example, here's Kevin Hoffman's [The .NET Addict] lead-off to his Jasper and IronPython in an ASP.NET Application post in the Project Codename: Jasper forum:
Every single demo that I've seen of Jasper has involved people using ipy [IronPython] to dynamically interrogate the database, which is fine. Also, the ASP.NET demos of Jasper have used VB as the code-behind language.
Here's the problem: both of those scenarios that I will never use in production. I will not be using VB in production, nor will I be using ipy in production.
What I'd like to see is:
- an ASP.NET application with IronPython as the code-behind
- an ASP.NET application with Ruby as the code-behind
Microsoft's Andrew Conrad replied:
Just curious, but are you saying you would be willing to put an IronPython or Ruby app into production, but not the same app written in VB? I would be curious to hear the reasons why?
To which Kevin responded:
I'm not saying that VB isn't a production-quality language. I'm saying that in the circles of people I associate with, no one will use VB. I don't know a single programmer who would willingly choose to write their code in VB. I make no claims as to the prejudicial attitudes of said programmers - only that I no [sic] of no one personally who prefers VB as a development language.
That said, in that same group of people, many of them find Ruby to be hip and cool, and Python to be equally cool and powerful.
But Kevin Hoffman's bio reads, in part:
Kevin Hoffman has been programming since he was 10 and has written everything from DOS shareware to n-tier, enterprise Web applications in VB, C++, Delphi, and C. [Emphasis added.]
and he's reported by Amazon.com to be the co-author of:
- ASP.NET Website Programming: Problem - Design - Solution, Visual Basic .NET Edition
- Professional ADO.NET with VB.NET
- Pro ADO.NET with VB .NET 1.1
- Professional ASP.NET Web Services with VB.NET
- Visual Basic .NET Deployment Handbook
Apparently, Kevin once thought VB was "cool" even if not "hip."
To its credit, Microsoft hired Beth Massi to evangelize VB, and Beth has done an amazing job of increasing the exposure of VB with Live from Redmond Webcasts and other video presentations, blog posts, and articles. Her July 17, 2007 LINQ Articles and More from the VB Team post summarizes recent works. The Visual Basic Team blog now appears to be much more active than Charlie Calvert's (C#) Community Blog. The technical level of the VB Team's articles has increased recently with single and serial posts by Kevin Halvorson, Matt Gertz, Jared Parsons, and Scott Wisniewski, although the LINQ Cookbook series would benefit from a dose of VB best practices.
Update 7/22/2007: Added Mitsu's many:many associations post and Paul Vick's lower-casing VB post.