Astoria
I was going to write
a blog post on Astoria but Pablo's post says almost everything I was going to
say.
I fully agree with
him, in that there are multiple scenarios where the default implementation will
be good enough, and it's much more productive than what we have today.
The fact that you can further filter the results of methods like 'CustomersByCity' is a significant step forward compared to the static service interfaces we usually have today.
On the other hand,
the client-side library has a WebDataContext class that knows how to track
changes in the client. The problem is that as the EF does not have a
change-tracking serialization mechanism (see previous posts) the way they have
to post a set of changes to the server is by executing multiple HTTP requests,
which is obviously a bad thing.
The good news is
that I think there's no way they can ship Astoria this way, so they'll need to
come up with a good disconnected story ;).
Pablo also mentioned
in his presentation that you'll be able to upload your EF model and the Astoria
live service will create the tables in the database and host up to 100Mb of
data. That's quite interesting, and it means they'll need to tackle another problem
(which it's solved quite well in DeKlarit) which is how to keep your data
stable when you deploy a new version of your model.