Further to my last post regarding Linq to SQL. I have been searching the net, looking for examples of how one might use Linq in an n-Tier world.
Short answer is there isn't really any. The vast majority of examples you will find are for a 2-tier model, where the DataContext is alive across the call, and the Entities will always be attached to the DataContext. Unless you are developing utilities, or you code will always be executed in the same box as the database, then this isn't really real world examples.
With a bit of digging, I have found a series of articles on the MSDN site here with the most useful being this one.
The readers digest version for those of you who are too lazy to read the articles, is that you need to serialize your Entities and then use the Attach API to "reattach" them to a DataContext.
There are some gotcha's, most important of all being you may have to handle concurrency issues yourself.
I intend on posting some code once I have digested the articles and found time to do some playing, but I would suggest you do some digging of your own, and those articles would be a good place to start.
3 comments:
Hi KB,
I've been digging around as this is something that I'm having issues with too. Namely now that I've managed to progress beyond the "ZOMG LINQ is SOOO Cool!!!" phase I'm coming to terms with the realisation that there are some serious limitations in what you can do with it.
It seems as though originally LINQ to SQL had as one of its objectives the idea of supporting some kind of n-tier architecture but I suspect that they decided that it was going to be too difficult in terms of managing objects over remoting links etc. Apparently Dinesh Kulkarni from the LINQ to SQL team admits that there is "no n-tier story in LINQ to SQL" (Here via Oakleaf)
Here is an interesting post from Keith Farmer which suggests that we are in danger of putting the pattern before common sense and that maybe a new look with fresh eyes is required.
I've looked at LINQ to Entities and haven't found it to be much different in terms of the n-tier limitations (but solves the complex entities problem with L2SQL that you mentioned in an earlier post) and comes with a whole bunch of buglets and wrinkles that make using it a bit hairy at the moment. What I'd be happy with is the ability to define the entities in a separate assembly OR the ability to use a tool to automatically generate intelligent presentation side classes which can supply the change state info etc which are derived from the "contract" on the business layer or something.
Crikey that was long... probably should have been a blog post in itself!
Irv
Hi, I'm in the same boat - the rose-tinted "LINQ to SQL" glasses are off and I'm hitting issues using it in the real-world in a tiered environment.
I did read somewhere (possibly Scott Gu's blog) that there would be a VS2008 extension out this year to support LINQ to SQL across tiers but I can't find the article now, and I haven't seen it mentioned anywhere else. Does anyone have any more info?
extensive work is done in this front in the tutorial by Microsoft - vs2008 and .net3.5 kit, they have used dinner now example.
little googling required
http://www.microsoft.com/downloads/details.aspx?FamilyID=8bdaa836-0bba-4393-94db-6c3c4a0c98a1&DisplayLang=en
enjoy and regards,
prabhjot
Post a Comment