C# in Depth

LINQ to SQL323FROM [dbo].[NotificationSubscription] AS [t2]WHERE [t0].[ProjectID] = [t2].[ProjectID]) AS [count]FROM [dbo].[Defect] AS [t0]LEFT OUTER JOIN [dbo].[NotificationSubscription] AS [t1]ON [t0].[ProjectID] = [t1].[ProjectID]ORDER BY [t0].[DefectID], [t1].[NotificationSubscriptionID]That’s a pretty major change in the amount of SQL generated! There are two importantthings to notice. First, it uses a left outer join instead of an inner join, so we wouldstill see a defect even if it didn’t have anyone subscribing to its project. If you want aleft outer join but without the grouping, the conventional way of expressing this is touse a group join and then an extra from clause using the DefaultIfEmpty extensionmethod on the embedded sequence. It looks quite odd, but it works well. See the samplesource code for this chapter on the book’s website for more details.The second odd thing about the previous query is that it calculates the count foreach group within the database. This is effectively a trick performed by LINQ to SQL tomake sure that all the processing can be done on the server. A naive implementationwould have to perform the grouping in memory, after fetching all the results. In somecases the provider could do tricks to avoid needing the count, simply spotting whenthe grouping ID changes, but there are issues with this approach for some queries. It’spossible that a later implementation of LINQ to SQL will be able to switch courses ofaction depending on the exact query.You don’t need to explicitly write a join in the query expression to see one in theSQL, however. We’re able to express our query in an object-oriented way, even thoughit will be converted into SQL. Let’s see this in action.IMPLICIT JOINS: SHOWING DEFECT SUMMARIES AND PROJECT NAMESLet’s take a simple example. Suppose we want to list each defect, showing its summaryand the name of the project it’s part of. The query expression is just a matterof a projection:// Query expressionfrom defect in context.Defectsselect new { defect.Summary, ProjectName=defect.Project.Name }-- Generated SQLSELECT [t0].[Summary], [t1].[Name]FROM [dbo].[Defect] AS [t0]INNER JOIN [dbo].[Project] AS [t1]ON [t1].[ProjectID] = [t0].[ProjectID]Notice how we’ve navigated from the defect to the project via a property—LINQ toSQL has converted that navigation into an inner join. It’s able to use an inner joinhere because the schema has a non-nullable constraint on the ProjectID column ofthe Defect table—every defect has a project. Not every defect has an assignee, however—theAssignedToUserID field is nullable, so if we use the assignee in a projectioninstead, a left outer join is generated:// Query expressionfrom defect in context.Defectsselect new { defect.Summary, Assignee=defect.AssignedTo.Name }Licensed to Rhona Hadida