Is V1 of LINQ to SQL only suitable for RAD?

Bigyan Rajbhandari — Tue, 25 Mar 2008 03:31:38 GMT

In my previous couple posts, I have been religiously trying to solve the problem or should I say 'find a best pattern' to use with linq to sql. In past few projects, I ventured into Linq to sql world abandoning ORM tools (OR mapper, NHibernate…) that I had been using; however, I have been greatly disappointed by the fact that Linq to sql doesn't support few fundamental concepts/patterns (LINQ to SQL takes a little different approach than traditional ORM tools). I am starting to have serious doubts if V1 of Linq2SQl is even cut out for any n-tier application (I am not even thinking enterprise application). Don't get me wrong, LINQ is a great framework and LINQ to SQL is an awesome extension. But in the real world business application the implementation of LINQ to SQL out of the box is not practical. How did I arrive to this conclusion? Here's how:

The two fundamental problems it fails to support out of the box are:

1. Working with objects in LINQ to SQL in disconnected context is painful. i.e. Most mid-large size applications are designed as n-tier architecture, thus entities within LINQ act more as a container (DTO or Business objects) for carrying data from one tier to another. The problem with LINQ to SQL is that disconnecting from one datacontext and reattaching to another is not trivial. This is a serious drawback given the fact that almost all the applications needs to use this model other than "quick demos".

I have seen lots of posts/articles from developers questioning the same problem. Various people have taken a stab at solving this, if you are seriously considering LINQ to SQL read these.

Benjamin's ULinqGen project in codeplex allows change tracking in pure POCO models
Post by Rick Strahl, explaining problem in Linq to SQL in a disconnected environment.
Matt's Linq2SqlEB project in codeplex which implements synchronization.

2. If you somehow implement an architecture to have live datacontext, one serious issue that you need to focus on is the lifetime management of DataContext. Please be aware, that poorly managed datacontext will bloat eventually and will hamper performance.

See my previous post on managing lifetime of datacontext
Rick Strahl discusses datacontext lifetime management here
Dino Esposito, suggest that you should use atomic context, but I don't see how it would solve the problem if you can't work in a disconnected environment.

Conclusion:
Am I ready to make jump to LinqToSql in my next project from my previous ORM tools? I don't know about others but, I will be holding back until I figure out a best way to work in a disconnected environment, which might be the next project. But the point is disconnected context support will be required. Dinesh Kulkarni, a senior dev for Linq to SQL team advises not use Active Record Pattern, but the problem is I don't see any pattern that I can use effectively in a n-tier architecture, not only the Active Record. LINQ to SQL itself uses great patterns within, but the way datacontext is managed and Entities/child entities are persisted it presents a different problem. It makes for a great presentation or RAD applications so far, but fails to support n-tier applications easily. I am considering concepts of offline datacontext and will follow up with more posts on this.

Is ADO.Net Entity Framework an answer?
Not really. The framework uses same concept of active context as Linq to SQL and quickly runs into the problem in a disconnected environment. I haven't done an in-depth implementation of it but the problem seems to be the same.

Let me know what you guys think of LINQ to SQL.

(Follow Up) Best practice and effective use of DataContext in LINQ

Bigyan Rajbhandari — Thu, 20 Mar 2008 21:46:24 GMT

NOTE: 3/24/2008 - The problem of working with LINQ to sql extends beyond lifetime management of DataContext, thus I am scrapping the second part of my blog. Only thing useful in this post is the performance comparision. Here's new post on LINQ to SQL

In my previous post, I had probed a question on how to effectively incorporate DataContext in ones pattern so the ease of use and unit of work is well represented. Thanks to everyone who provided feedback, it definitely was a good read and provided lots of insight. Few reasons we got into asking this question instead of using simple create/dispose model, in the first place was

We wanted to make it so that it was easy to use
We heavily use Repository Pattern for business logic/transaction scoping and Entity model for CRUD operations, so wanted to make sure datacontext we used was as efficient as possible.
Concerns regarding efficiency of creating/disposing datacontext and not being able to use caching of datacontext effectively.

~~However, after reading several posts and looking deeper into datacontext, it seems that creating/disposing it as required is the best way to go~~. In order, to get rid of any suspicion I even created a little test to compare Ambient Context and Instantiation as required model, results are below. In the image below, first method GetByID(int32) actually instantiates datacontext everytime, where as the second one takes in a datacontext instantiated once by the caller (code is included at the bottom of the post). The results are impressive for dynamic instantiation. 23.7 secs vs. 20.9 secs for 6200 iterations. I think 3 secs is a reasonable margin not taking into account impact in memory with ambient datacontext or the efficiency of caching.

Either way, I believe for our purpose and in general a repository pattern incorporated with entity model should work pretty well. One thing Jeff did point out to me however was, once you have disposed your datacontext, any attempt to load/access child objects that is marked for lazy load will throw disposed object error as below. So make sure you load your objects while the context is alive, once that is done subsequent access is successful.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Timers;
using System.Diagnostics;

namespace ConsoleApplication4
{
    class Program
    {
        static void Main(string[] args)
        {
//Create & dispose Context everytime
            Test1();
            
        //Ambient Context Concept
Test2();
        }

//Create datacontext everytime
        private static void Test1()
        {
            List<EcardOrder> orders;
            using (MercyDataContext dbContext = new MercyDataContext())
            {
                for (int i = 0; i < 100; i++)
                {
                    orders = dbContext.EcardOrders.ToList();
                    foreach (EcardOrder order in orders)
                    {
                        //Datacontext will be created everytime 
// in this function
                        Ecard card = Ecard.GetByID(order.EcardID);
                    }
                }
            }
        }

        
//Create datacontext only once
        private static void Test2()
        {
            List<EcardOrder> orders;
            using (MercyDataContext dbContext = new MercyDataContext())
            {
                for (int i = 0; i < 100; i++)
                {
                    orders = dbContext.EcardOrders.ToList();
                    foreach (EcardOrder order in orders)
                    {
                        //Pass datacontext to the function as well
                        Ecard card = Ecard.GetByID(order.EcardID, dbContext);
                    }
                }
            }
        }


    }

    /// <summary>
    /// Partial Ecard class extended from database
    /// </summary>
    public partial class Ecard
    {
        //new datacontext is created and disposed everytime.
        public static Ecard GetByID(int ID)
        {
            using (MercyDataContext _context = new MercyDataContext())
            {
                return _context.Ecards.SingleOrDefault(e => e.EcardID == ID);
            }
        }

        //Puesdo concept of ambient datacontext
        //NOTE: once the Ecard is loaded it is cached in the context, 
        //thus items will be returned from cache
        public static Ecard GetByID(int ID, MercyDataContext _context)
        {
            return _context.Ecards.SingleOrDefault(e => e.EcardID == ID);
        }
    }


}