Note: This post is updated daily or more often, depending on the availability of new articles.
Mike Tulty Defines Update Functions in SSDL, a QueryView in CSDL, and Maps the QueryView and Update Functions in MSL
Once you review the schema additions that Mike makes to define functions to return, insert, update, or delete QueryView entities, the inline functions appear straightforward. His ADO.NET Entity Framework - QueryViews, Inline Functions post of February 8, 2008 shows the modifications to the SSDL, CSDL and MSL files required to create a custom QueryView as the UkCustomers EntitySet and provides InsUkCustomers, DelUkCustomers, and UpdUkCustomers functions to update the EntitySet.
Mike points to Julie Lerman's EDM QueryViews vs Defining Queries (and read-only views)treatise of November 2, 2007 about the difference between QueryViews and DefiningViews.
Added: February 9, 2008 Clarified: February 10, 2008
Eden Ridgway Updates Emile Bosch's LINQ to WMI Provider to .NET 3.5 RTM
In his An Updated LINQ to WMI Implementation post of January 2, 2008 (which I missed in the first linkblog of the new year, Eden describes his update to Emile Bosch's 2005 implementation (Query your WMI with ease using WMILinq! of December 12, 2005) which was based on the May 2005 CTP running in VS 2005.
Added: February 9, 2008
SQL Server Compact Edition Team Posts SSCE 3.5 Build and Availability List
Laxmi Narsimha Rao Oruganti's SQL Server Compact Release Versions post of February 8, 2008 lists the product name, release vehicle, and version numbers for each release of SQL Server 2005 Mobile 3.0 and Compact 3.0 and 3.5 Editions.
SQL Server Compact 3.5 SP1 Beta for ADO.NET Entity Framework Provider Beta (v.3.5.5626) is of particular interest to Entity Framework pilgrims, which Laxmi's post says available from the Download Center. The latest version I can find that's available for download is Microsoft SQL Server Compact 3.5 and Microsoft Synchronization Services for ADO.Net v1.0 for Windows Desktop (v.3.5.5386.0).
A question about availability of v.3.5.5626 is pending as a comment.
Added: February 8, 2008
Bart De Smet Updates LINQ to SharePoint Alpha for VS 2008 RTM
Bart's LINQ to SharePoint 0.2.4 alpha release for .NET Framework 3.5 and WSS 3.0 CodePlex release offers these features
- LINQ query provider for runtime translation of LINQ queries to CAML queries
- Support for both C# 3.0 and VB 9.0
- Debugger visualizer for LINQ to SharePoint queries
- Entity creation wizard for Visual Studio 2008
- SpMetal tool for SharePoint list entity creation
- MSI setup
updated to Visual Studio 2008 RTM bits.
Important: Read the Release Note for instructions to load the four LINQ to SharePoint libraries into the GAC, which is required for this drop.
Added: February 7, 2008
Dramatically Poorer Performance of VB Than C# LINQ to SQL Queries
Stefan Sedich's Different SQL between C# and vb.net using LINQ to SQL causes performance issues post of January 7, 2008 demonstrates a major difference between the T-SQL generated by VB & C# versions of the same (somewhat complex) LINQ to SQL query.
Subtree cost for the C# version was 0.1; the VB version's subtree cost was 7.3.
Similarly, the execution plan reports that the C# query's cost was 2% of the batch, which the VB query was 98% of the batch.
Frans Bouma's comment suggests reasons for overall poor query performance as well as the cause of the VB query's problem (the WHERE(COALESCE(CASE ... )) clauses.
Added: February 7, 2008
Update February 12, 2008: Stefan's Different SQL between VB.NET and C# LINQ to SQL SOLVED!! post of February 12, 2008 describes the cause of VB's added (COALESCE(CASE ... )) clauses: VB treats database fields that allow nulls differently from C#. Note that Northwind tables allow nulls in foreign-key fields that would throw referential integrity exceptions if set to null.
Beth Massi Demonstrates Populating Combo Boxes with LINQ to SQL
Beth's Related Data Binding and ComboBoxes with LINQ to SQL post of February 6, 2008 describes how to substitute a combo box bound to an Object Data Source to serve as the master navigation tool to populate a DataGridView with related (child) records. The example she uses assigns Regions to the combo box and Territories to the DataGridView. Making a selection from the combo box's list is similar to doing the same with a BindingNavigator or a master DataGridView.
Added: February 6, 2008
Open Source Profiler for SQL Server 2005 Express
Stefan Cruysberghs' .NET - ADO.NET Entity Framework & LINQ to Entities - part 2 post of February 6, 2008 covers the following topics:
- SQL profiling tools
- Microsoft SQL Server Profiler
- AnfiniL's SQL Express Profiler
- ToTraceString method
- Entity SQL : EntityCommand.ToTraceString()
- Entity SQL : ObjectQuery.ToTraceString()
- LINQ to Entities : (query as ObjectQuery).ToTraceString()
I'd never heard of AnfiniL's SQL Express Profiler so decided to give it a try. It's relatively Spartan, as indicated by the following screen capture of a LINQ to REST query, but it does the trick for LINQ implementations that don't offer LINQ to SQL's Log property or where you want a quick way to display autogenerated T-SQL.
David Hayden Demonstrates LINQ to SQL and Repository Pattern with ASP.NET MVC
The presentation included a "sample ASP.NET MVC Application in question helps developers manage and promote their developer events." David says:
He also includes the code for the AttendeesController and List action.
Added: February 6, 2008
Scott Walker Implements the Specification Pattern for Validation and Object Selection with LINQ
Scott's Specifications, LINQ, and Lambdas post of February 5, 2008, traces his evolution "to a more DDD oriented model than a CSLA oriented one" and "the main challenges [in finding] the right way to do validation." Scott says,
This got me to thinking about the specification pattern as this type of validation is just one of the cases that pattern can be used for. The other great use of this pattern is for selecting a subset of objects from a master list, which ties in very well with the repository pattern for object retrieval. This line of thinking eventually lead me to the idea of somehow creating an implementation of the specification pattern that could be used for both validation and entity selection (using LINQ) types of scenarios. It seemed like a reasonable goal and one that could be very beneficial if done correctly.
Scott has posted the source code here.
Added: February 6, 2008
Rick Strahl Updates His LINQ to SQL Business Object Wrapper
Rick posted an Update to LINQ to SQL Business Object Wrapper Sample for .NET 3.5 RTM on February 5, 2008. The lightweight wrapper and a simple TimerTracker demo progect originally appeared in his A simple Business Object Wrapper for LINQ to SQL post of September 27, 2007. You can download the updated code here.
Added: February 6, 2008
Julie Lerman: Instructions for Precompiling Entity Framework Views for Faster Startup
Brian Dawson (see "Brian Dawson Begins Series to Analyze Entity Framework's Performance Problems" below) and Julie Lerman (see Entity Framework Performance of February 5, 2008) observe that precompiling the view reduces Entity Framework's start up query time. This feature is new in Entity Framework Beta 3.
Jaroslav Kowalski provided the step-by-step instructions and the XML precompile piece of XML in an answer to Julie's EF: Best way to compare apples to apples when comparing perf of materialized objects vs datareader? December 13, 2007 question in the ADO.NET (Prerelease) forum.
Danny Simmons concluded:
[Julie's] timings are pretty reasonable. The exact numbers and ratios between the various techniques will depend a lot on the complexity of the model and other factors, but view generation is typically very time consuming (which is why we made it possible to do it at compile time) while executing queries through object services has improved dramatically to the point where for some scenarios it is the same speed or better than using the DataReader on EntityClient (as you observed).
Added: February 6, 2008
Jim Wooley's Extension Method Creates LINQ to DataReader
Chalk up another LINQ to Whatever implementation: LINQ to DataReader. Jim provides the details and a sample C# extension method with a VB test harness in his Consuming a DataReader with LINQ post of February 5, 2008.
Neither Jim nor I made comparative timings, but I'd bet the process is several times slower than reading the DataReader directly.
Added: February 6, 2008
Charlie Calvert's LINQ Farm Seed 1 and 2: The Aggregate Operator
Charlie continues his series with LINQ Farm Seed I: Aggregate Operator Part I of February 5, 2008 and LINQ Farm Seed 02: Aggregate Operator Part II of February 6. Source code for both episodes is available from CodePlex.
Added and Updated: February 6, 2008
Rick Strahl Tackles LINQ to SQL DataContext Persistence Issues
Rick's Linq to SQL DataContext Lifetime Management post of February 5, 2008 discusses trade-offs with LINQ to SQL's top-level DataContext object. He analyzes the following options for persisting the DataContext for multiple operations (or not):
- Create a new Context for each atomic operation (Application level management)
- Create a global DataContext and handle all operations against this single DataContext object
- Create a thread specific DataContext
- Create a per business object DataContext
and provides source code for the last two approaches. Here's Rick's conclusion:
In the end the key for DataContext change management is to ensure that the DataContext is always accessible and doesn't need to be recreated. As long as you can find some way to hang on to a single data context it can be used and be expected to correctly deal with change management.
Unfortunately as I pointed here and here , once you disconnect from the DataContext, the story with LINQ to SQL reconnecting and synching with another DataContext is bleak at best. So the best strategy is to keep hanging on to to the DataContext if you at all can <shrug>. Not always possible when you really need to cross machine boundaries with Web Services, but at least in that scenario you do get a fresh de-serialized instance of an object that can potentially be resynched by using Table.Attach().
For anything else it'll be better to implement something like one of the strategies above to hang on to your DataContext.
Entity Framework's ObjectContext has characteristics that are similar to LINQ to SQL's DataContext object. Therefore, Rick's conclusion probably applies equally to EF implementations.
Any .NET developer who has adopted or is considering implementing either LINQ to SQL or Entity Framework should read this well-researched post (and its comments) carefully.
Brian Dawson Begins Series to Analyze Entity Framework's Performance Problems
The ADO.NET Team's Exploring the Performance of the ADO.NET Entity Framework - Part 1 post of February 4, 2008 by Brian Dawson, an ADO.NET program manager, starts by analyzing what occurs in the 4.241 seconds required to run an initial ObjectQuery. View generation (creating data store views) is the primary performance culprit, consuming 56% of initial query time or 2.375 seconds.
My tests confirm Brian's 4+ second initial query times for simple LINQ to REST queries against basic ADO.NET Data Services with Entity Framework back ends, as well as WCF Web Services that use EntityBag objects. (See my "Notice the 4-second delay between completion of the request and response messages." at the end of my Logging EntityBag's SOAP Request and Response Messages post of January 29, 2008).
Update 2/5/2008: Added WCF Web service quote to the above.
Brian says, "The good news is there is a way of making view generation part of the build process so that this step can be avoided at run time." If the step were eliminated, the query time would be 1.866 seconds.
However, he goes on to say:
When I run the EDM generator (EdmGen.exe) command line tool with the view generation command parameter (/mode:ViewGeneration), the output is a code file (either C# or Visual Basic) that I can include in my project. Having the view pre-generated reduces the startup time down to 2933 milliseconds or about a 28% decrease.
2.933 seconds for an initial query doesn't mesh with the 1.866-second result calculated with the step eliminated. This issue needs further investigation.
The problem is that even 1.866 seconds is too long an initial spin up time for conventional WebForm apps.
Successive queries execute, for the most part, in 13 or 14 ms. However, one query took 24 ms. to execute. I add timers to all my WinForm Entity Framework clients and find the same anomalies in my tests.
Brian promises to "show some of the performance improvements that can be made on the query itself and how Entity SQL and LINQ to Entities perform" in his next post.
Mike Flasko Explains "Why ADO.NET Data Services?"
Mike's Why ADO.NET Data Services Framework (aka Astoria)? is a compilation of his replies to questions in the ADO.NET (Pre-Release) forum about the ADO.NET Team's "motivations for ... building Astoria."
My take is that the Entity Framework folks needed a quick and easy demo of a practical use of the Entity Data Model, just as LINQ to SQL began as a demonstration of the capabilities of LINQ as a whole. The problem, of course, is the four-second delay in delivery of the initial query result that's described in the preceding topic.
Charlie Calvert Starts "LINQ Farm Seeds" Series by Showing How to Enumerate LINQ Standard Query Operators
Charlie's LINQ Farm Seed 0: Operators in LINQ to Objects post of February 4, 2008 demonstrates the use of "LINQ to Reflection" to enumerate LINQ to Objects' Standard Query Operators. Source code is available from CodePlex.
I believe the first use of the term "LINQ to Reflection" to refer to LINQ queries that use reflection occurred in the book Introducing Microsoft® LINQ by Paolo Pialorsi and Marco Russo, which is now available as a free download from Microsoft Press. A "LINQ to Reflection" Google search receives only 6 legitimate hits, so the term isn't in widespread use.
Pablo Castro Delivers Entity Framework and ADO.NET Data Services Podcast
SQL Server Product Group member Pablo Castro discusses LINQ, Entity Framework and ADO.NET Data Services for the DBA and database developer.
Off-Topic: Jacob Profitt Contests Conclusions of Canadian Test-Drive Development Paper and Its Analysis by Phil Haack
Test-driven development (TDD) is ingrained in most professional .NET programmers' approach to enterprise development. TDD implies a test-first, code-later approach, which was the subject of a Canadian research report, "On the Effectiveness of Test-first Approach to Programming." Microsoft senior program manager Phil Haack based his Research Supports The Effectiveness of TDD post of January 22, 2008 on the conclusions of the report.
However, developer Jacob Profitt more closely analyzed the study's findings and found that they lacked support for Phil's post. In fact, Jacob concluded that the study actually found:
- The control group (non-TDD or "Test Last") had higher quality in every dimension—they had higher floor, ceiling, mean, and median quality.
- The control group produced higher quality with consistently fewer tests.
- Quality was better correlated to number of tests for the TDD group (an interesting point of differentiation that I'm not sure the authors caught).
- The control group's productivity was highly predictable as a function of number of tests and had a stronger correlation than the TDD group.
So TDD's relationship to quality is problematic at best. Its relationship to productivity is more interesting. I hope there's a follow-up study because the productivity numbers simply don't add up very well to me. There is an undeniable correlation between productivity and the number of tests, but that correlation is actually stronger in the non-TDD group (which had a single outlier compared to roughly half of the TDD group being outside the 95% band).
Jacob then goes on with a detailed interpretation of the report.
I tend to code first and test later because it allows me to refine the tests to more precisely suit the project's objectives and implementation.