State vs Statement of Intent
Well I went to Vegas for Dev Connections.
What an experience. Never been there before, but for first two days I was too worried about my two talks to take much in.
My first talk was Entity Framework in a world of Services and Processes.
My old boss Tim came up with the title, I was left to fill in the blanks.
It went pretty well. 250 or so people in the room, standing room only, and despite the fact I haven't seen any evals, I think it was pretty well received.
The presentation was an excellent opportunity to kill two birds with one stone, namely:
- Educate everyone on N-Tier support in Entity Framework v1
- Uncover limitations and discuss underlying principles
If you've ever met me or been to one of my presentations, I hope you realize my focus is always on underlying principles.
With good reason I think: if you can establish principles, they can make the complicated seem easy.
So lets set the stage:
When a client tier modifies an object graph, and you the programmer, expect to easily apply those changes on the server tier, suddenly a whole slew of problems, concerns and gotchas come out of the wood work.
I think however there are some underlying principles at work.
Maybe all these issues are simply pieces of evidence that point to the real culprits:
- Inferring and serializing intent
- Satisfying intent
In my presentation I put up a slide titled "State vs Statement of Intent", and here's why...
Most programmers think they should just be able to send an updated object graph, and have changes applied to the database, with very little fuss.
But if you look at the problem the right way, through the "lens of intent" suddenly you can see that if you have just a final graph, you can't possibly:
- Know what is new and what is old?
- Know what has been deleted?
- Distinguish between, an instruction to remove relationships and simple lack of knowledge of the original relationships?
- etc etc etc
It boils down to this, an object graph is just "State". It has no associated "Statement of Intent".
And if you don't know what the client tier intended how can you possibly do it?
Assuming you can solve this problem, i.e. once you know the intent, the second half of the problem, satisfying it, should be pretty easy.
Given these principles you can look at the Entity Framework v1 with a fresh set of eyes.
Today both of these problems can be a little tricky. We don't really provide anything to help you infer intent. Often this doesn't matter, but there are plenty of compelling scenarios where some extra help would be really handy.
And today once you do know the intent, the methods we provide for "telling" the Entity Framework what to do, aren't ideal. This means users sometimes have to do some pretty interesting graph manipulations just to be able to "tell" the Entity Framework what to do.
The good news is we are working on both of these problems in V2.
Comments
- Anonymous
November 24, 2008
PingBack from http://blog.a-foton.ru/index.php/2008/11/24/state-vs-statement-of-intent/ - Anonymous
March 23, 2009
Lots of the feedback we got on the EF design blog about our early N-Tier plans , highlighted that lots - Anonymous
May 14, 2009
Building applications that work across tiers is a core part of many application architectures. In .NET - Anonymous
May 17, 2009
So sending the end result has little value if you don't have information on the original, I get that. The posts suggests sending the original + the new object.But is it not possible to compare against the original object on the server (insert and delete intent should also be easy to relay).Also, are new and old objects sent in their entirety? Why not just send the original + difference, just like a source patch? - Anonymous
May 25, 2009
  Building applications that work across tiers is a core part of many application architectures