LINQ and Client Server Applications

First of all I would like to apologize for not posting links, for various sources I acquired knowledge from, because a week has passed after reading them and I don’t remember which is which.

Last week I was doing some research for LINQ and how it could be integrated in the applications I develop for my company. There is something on the net, that always keeps bugging me and I prefer to have my own opinion. Always everything is great, but there always seems to missing the parts that things are not good.

In a few words LINQ is an ORM that ships with .NET3 and from what I have seen it is very good. Truly all the great things that have been talked about are there, and even better for me. But something that stroked odd for me, was the fact that there was no single mention about Client – Server applications or known as N-Tier.

I’m not a Web Developer. I develop Smart Client Applications where the notion of disconnected from the data source is the biggest truth.

Every example in LINQ that I had saw, assumed that my application has a direct and steady connection to the data source, exactly like a web application. That maybe true for web in many cases, but in other applications is not. I tried LINQ with just one entity and sub collection, sending it to the client and bringing it back to the server, and all hell broke loose. For just a single entity, logic should be applied on how you should attach your entity to the data context. And I didn’t get to deletion.

There are two ways to manage data in disconnected state. Either you write your own mechanism or use Datasets. I prefer the latest, and especially Typed Datasets for various reasons one of which is the version mechanism that dataset have embedded inside. So I tried to search about Datasets and LINQ and there was just a little.

So I did a little research and found out that …

First of all there are two types of LINQ. LINQ to SQL and LINQ to DataSet. Both do the exact same thing, that is to query collections ,with one huge difference. LINQ to SQL queries collections directly to your data source and LINQ to Dataset queries basically your own dataset. My biggest disappointment was when I found that in the original beta, there was a functionality that converted datasets to entities and reverse, but a developer of Microsoft in his blog, mentioned that they didn’t have the resources to implement it in the current version.

My thought is that when building a framework with business objects and a data access layer that supports its persistence wouldn’t it be great to have Entities-like objects for web and a disconnected version of them for smart clients? This would be, that SQL would be reduces significantly and both application types would utilize the same idea. The only missing link is the mechanism to convert between entities and datasets without having to write extra code.

The above missing link was what I was developing a whole week. It started as a proof of concept, but it became something that I think has great potential, because I like the idea of LINQ especially for Web Applications, which I believe will be optimized even more by Microsoft, I like typed datasets for disconnected Applications and the only thing missing was something that connected them.

This post was like an introduction for my next post, that is the converter project it self.