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.
-
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.