LINQ to SQL Lives On

Many database developers have loudly bemoaned Microsoft's decision late last year to marginalize LINQ to SQL in favor of its ADO.NET Entity Framework.

The angst played out as many who build applications designed to access Microsoft's SQL Server felt left holding the bag as reported here . Make no mistake: the Entity Framework is Microsoft's object relational mapping (ORM) technology of choice and that will become even more evident next year with the release of Entity Framework 4, Visual Studio 2010 and the .NET Framework 4.

Hence there will be no major emphasis on LINQ to SQL from Microsoft other than some fixes and occasional tweaks. To many that decision was an unfortunate turn of events because LINQ to SQL is faster and easier to work with than the Entity Framework, many developers say. And if all you're trying to connect to is SQL Server, it does the trick, whereas the Entity Framework at some point will become more appealing to those looking to connect with multiple vendors back-end databases.

But there have been some positive developments for those who intend to stick with LINQ to SQL. For one, Microsoft did make some improvements to it in the .NET 4 Framework, noted Damien Guard, a software development engineer within Microsoft's Data Programmability Group (see his June blog posting).

For those who don't feel that's enough, Tony Sneed, a consultant and trainer, believes those looking to use an ORM for SQL Server will be better off using LINQ to SQL rather than the Entity Framework. In a blog posting last week, he pointed to a client, Credit Solutions, who successfully used LINQ to SQL for a line-of-business application  "You're going to get up and running much more quickly with LINQ to SQL than you would with Entity Framework," Sneed said in an interview.

But the question he pointed to in the blog posting: "who is adding new features to LINQ to SQL?" The first viable alternative he has come across is PlinqO, developed by code generation tool supplier, CodeSmith.  Sneed explained in his posting:

The purpose of PlinqO is to generate LINQ to SQL entities that replace those created when you add a dbml file to a Visual Studio project. In fact, PlinqO will generate the dbml file for you, placing each entity in a separate .cs file under a common folder. Actually, PlinqO creates two files: one for the code-generated entity, and another for your own custom metadata that will not be overwritten by the code-generator (for example, attributes that can drive a dynamic data web site).

I spoke with Shannon Davidson, general manager at CodeSmith, to see if he is expecting a broad market to provide code-generation for LINQ to SQL. "We've had a lot of people tell us they are still not happy with the Entity Framework and that LINQ to SQL is a lighter framework, and is easier to use, and the performance speeds have been faster on LINQ to SQL than Entity Framework so far," he said.

Still LINQ to SQL has its own quirks, Davidson said, such as creating original DBML (database markup language), the XML-based language that describes databases. As Sneed pointed out, developers who use PlinqO don't have to use the designer to create the original DBML, nor do they have to remove and re-add entities to the DBML designer. "When using regular DBML, I noticed that it's a little flakey as far as how it re-generates the code and I also noticed it deleted files that I didn’t want to delete," Davidson said. With the CodeSmith templates you can make your data changes, you write-click and re-generate and your DBML is automatically updated, he said.  

Also addressing a big complaint that LINQ to SQL didn't let developers detach entities, PlinqO supports detaching of entities, he said. The templates are free to those CodeSmith tools users (the professional edition costs $299).  While Davidson sees a lot of interest in LINQ to SQL intends to offer tools for Entity Framework 4 and just last week released Nhibernate templates (see last week's update on Nhibernate here)

Indeed while PLinqO is getting a lot of buzz in Twitter land, it's not the only option for improving LINQ To SQL. MVP Jim Wooley, an expert in both LINQ to SQL and the Entity Framework and author of the book LINQ In Action pointed out in an email interview there are other options. One alternative is from Huagati, a company in Bangkok, which Wooley noted offers some of the same features that PLinqO has.

Wooley pointed to some other worthy options for the initiated. One is the LINQ to SQL Templates for T4 Project, designed for those looking to develop customized code generators (see Microsoft's CodePlex site). "I think the L2ST4 project has a lot to offer, particularly in terms of Visual Studio integration," he noted. "Many of those that are attracted to PLinqO like it for some of the built in functionality that they don't want to customize. Both of these alternatives are limited in their abilities as many of the customizations that people want require changes to the underlying provider which is not exposed publically in the framework."

Other options, Wooley noted, include the IQueryable Toolkit, contributed to CodePlex by Matt Warren, a software architect on Microsoft's C# programming language product team and the Mono LINQ to SQL implementation for people interested in extending LINQ to SQL. Wooley also said developers could try to combine these projects with the Entity Framework Provider sample to try to implement enhancements to Entity Framework, should they choose to go down that path.

Don’t look to any of these options to become a broad trend, according to Wooley. "None of these options are trivial undertakings, thus I wouldn't be surprised if less than 1 percent of the developer population would consider going down this route," he noted.

 "The bottom line," according to Sneed in his blog posting, "is that LINQ to SQL is a perfectly viable alternative when you can guarantee that the database will be Microsoft SQL Server (2000 or later). It has support for POCO (persistence ignorance), stored procedures, lazy loading, and concurrency management, and it works well with SOA (n-tier) architectures."

Beneath this backdrop, do you plan to continue your efforts with LINQ to SQL? Do you see ultimately becoming proficient in the Entity Framework or are you going to focus on Nhibernate. Granted this isn't an either or decision for many but we'd like to hear your opinions and issues so we can further report our findings. Feel free to post them here, or drop me a line at [email protected].

Posted by Jeffrey Schwartz on 08/10/2009