Maybe a bit more background would explain why I am after the batching behaviour. Our application has screens to manipulate resources, but the screens don't map one to on to the resources, so e.g. a single screen would do edits on multiple resources (all
of those are parent-child related). Up until now we have modeled this by having one big model per screen that is posted and then taken that apart at the server in order to update our data model. This worked, although for just a couple of screens we already
had an explosion of viewmodels which contained similar logic in javascript and in C#. Another disadvantage of this approach is that our API is totally useless for anything but our application.
My idea with the batching was to eliminate the serverside screen logic and have a 'simple' resource model on the server, which would make consuming our API for other applications easier.
As an example, where we would previous have this:
Model in javscript containing parent resource changes and child resource changes (like add one, delete another, update yet another) and have that send to the API where it would be bound to a C# model and then taken apart at the server to update our data
model.
It would be replaced with:
Model in javscript containing parent resource changes and child resource changes which post the individual resource changes to the server in a batch:
1. Update parent
2. Add child
3. Delete child
4. Update a child
As a bonus the batch could run in a single transaction.
Any obvious solution that I'm overlooking for this?
bccoltof
Member
10 Points
5 Posts
Re: Batching Web API calls
May 25, 2012 08:04 AM|LINK
Hi,
Maybe a bit more background would explain why I am after the batching behaviour. Our application has screens to manipulate resources, but the screens don't map one to on to the resources, so e.g. a single screen would do edits on multiple resources (all of those are parent-child related). Up until now we have modeled this by having one big model per screen that is posted and then taken that apart at the server in order to update our data model. This worked, although for just a couple of screens we already had an explosion of viewmodels which contained similar logic in javascript and in C#. Another disadvantage of this approach is that our API is totally useless for anything but our application.
My idea with the batching was to eliminate the serverside screen logic and have a 'simple' resource model on the server, which would make consuming our API for other applications easier.
As an example, where we would previous have this:
Model in javscript containing parent resource changes and child resource changes (like add one, delete another, update yet another) and have that send to the API where it would be bound to a C# model and then taken apart at the server to update our data model.
It would be replaced with:
Model in javscript containing parent resource changes and child resource changes which post the individual resource changes to the server in a batch:
1. Update parent
2. Add child
3. Delete child
4. Update a child
As a bonus the batch could run in a single transaction.
Any obvious solution that I'm overlooking for this?