The future of Disconnected LINQ

Apr 21, 2008 at 9:13 PM
First let me say that I like the work you have done so fare. You have proven that a little convention and some smart thinking can take you fare. And it’s also making me wonder why Microsoft hasn’t baked this into the framework.
But I only see this as the beginning. I think that the EntityBase should be but in a new class maybe with the name DisconnectedContext. And the class should act as a transport container for the graph of objects.
Some advances that the DisconnectedContext could give are.
• Return of errors from the server in a uniform way.
• Validate the object graph before sending it to the server.
• Only send dirty data to the server and merge the result on the client. Like the dataset.
• Using the NetdataContractSerializer maybe using the dataportal from CSLA
I guess there are many more. But with the feature set from above we could start a lightweight CSLA project. If you feel that this is the right way for you project then I will be happy to join you.
And don’t forget that the world is crying for a project like this :-)
Apr 24, 2008 at 1:03 AM
Thanks for the feedback.

I have mentioned very briefly on my blog that it would be possible from what I have learned so far to create a disconnected context. It would work very similarly to what I have now, but there are some technical differences that means some re-thinking perhaps. I feel it might feel a little more "natural" to have a disconncected context object - similar to what is in "connected" mode.

I suppose I wasn't really trying to write a framework, just trying to build on what's there and fill in the gaps.

I like your ideas, what I might do is just port the LINQ 2 SQL Base class to a seperate class first then I'll start to build on that.

Free to post any more idea's, and I'll have a think about those you've already come up with ;).