Data Driver

Blog archive

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 jschwartz@1105media.com.

 

Posted by Jeffrey Schwartz on 08/10/2009 at 12:52 PM


comments powered by Disqus

Reader Comments:

Thu, Jul 1, 2010 Rik Florida USA

Viva Linq to SQL. Until EF can perform as fast on SQL SERVER, I am using Linq to SQL. I agree MS seems to have a case of ADD when it comes to technologies and methods. Just when one get traction it is no longer in vogue and we all must jump to this other model that offers more abstraction, and less performance. To what business value? I develop on MS tools. I could care less about adding another DB. Give me the fastest DAL for SQL Server period that what i will use.

Thu, Feb 4, 2010 debt consolidation http://www.outtadebt.com

I don't know techno speak, but I hope this doesn't mean they are rolling out a new operating system.

Thu, Sep 10, 2009 ANANTHARAMAN CHENNAI , INDIA

Apart from debating on whether LINQ to SQL is better than ADO.NET Entity Model / NHibernate / Spring.NET , the real need is to build better data schema abstraction , security & performance features in ORM technologies to convince those DBAs & Architects who still believe that ad hoc SQLs are not better than SPs and that SPs provide the secure data gateway for information access without exposing DB schema.

Thu, Sep 10, 2009 80s Rocker

So just because there is no new features and it is just in maintenance mode is a reason to not use LINQ to SQL. That is ridiculous. So if that is a good reason to not use a certain API then you should not use half the .Net framework. For example, when were the last big changes made to the following. - asmx web services - the math functions of .Net - the string functions of .Net - WinForms - WebForms Using LINQ to SQL might actually be smart if it meets you needs since there will not be any drastic changes. This means you will not get steamrolled by a major enhancement introduced that breaks all your existing code when you upgrade. Long Live "LINQ to SQL".

Thu, Sep 10, 2009 Peter Herschel Philadelphia PA

What bothers me is not that Microsoft constantly creates new technologies, it is that they to readily a abandon older ones. How I would love to see improvements to classes / APIs we've built our production systems on. They are always looking ahead - leaving mainline developers in a constant mode of catchup. This phenomenon occurs through out their libraries and even more so when the technology allows for rapid development.

Sat, Aug 15, 2009 Denis Kitchen

What makes a platform or tool most compelling? Not the features. Not the vendor. Certainly not the marketing. It's the community. Linq to SQL has a lot of love out here in the real world. Also, can we agree that LINQ will be around for a very long time (decade or more)? Can we same the same about SqlServer? For sure. Fine that settles the matter. While linq exists and sqlserver exists, so will linq2sql. What the hey is EF? Do you really believe that EF has or will enjoy the same level of community support of sqlserver?

Wed, Aug 12, 2009 Alan

LINQ to SQL is here to stay. Unless LINQ to Entities is updated to provide a seamless switch away from LINQ to SQL, I will not be dropping LINQ to SQL, and I doubt anyone who has already built software on top of it will either.

Wed, Aug 12, 2009 Erik Johnson San Diego, CA

The IQToolkit project on CodePlex is worth a look. Lot's features and well-optimized for SQL Server. It's also designed for extensibility and includes a bunch of unit tests. With some work, you can get it to perform better than Linq to SQL. Even if you don't use it in production, you can learn tons from it.

Mon, Aug 10, 2009 Ron Stevenson Bellevue, WA

I hate to say it, friends, but ANY technology employed must be considered temporal. In time, even ADO.NET Entity Framework will be superceded by something from Microsoft deemed better, faster, more complete, or richer.... Has any technology, language, protocol or standard which you've employed in the past, not been eventually replaced by 'the next big thing' in development tools, platforms or frameworks, along with a significant learning curve?

Mon, Aug 10, 2009 Brian Mains Harrisburg, PA

I do not plan to use LINQ to SQL anymore. Even though LINQ to SQL is a viable option, it has no future. Because of that, I feel it's better to do with a product line that will continue to receive enhancements, and not just be stuck in maintenance mode. Plus, as time goes on, LINQ to SQL resources will continue to lessen compared to its successor ADO.NET Entity Model.

Add Your Comment:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Comment:
Please type the letters/numbers you see above