Hey Frans,
Thanks for the explanation. We're a few days later now and my work progressed immensely.
I really want to use the json, to keep an open road for web clients, mobile clients, etc in the future.
But actually, LLBLGen is very well suited for this scenario, because of it's finegrained control over the Fields, with their IsChanged, DataType, CurrentValue properties. It makes it very simple to send back the modified data from client to server in a "patch" object. (inspired by http://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/ )
All in all, I'm very happy with the results, nice clean code, great performance, and fully "open standards". Once again, LLBLGen delivers.
It makes for very clean code, eg the Patch method on the WebAPI controller:
[HttpPatch]
public TestEntity Update(int id, IEnumerable<FieldPatch> patches)
{
TestEntity entity = new TestEntity (id).MakeNonDirty();
foreach (var p in patches)
p.Patch(entity);
using (var adapter = new DataAccessAdapter())
{
adapter.SaveEntity(entity, true);
return entity;
}
Clean and superfast, because the database only gets hit to update the changed fields.
The FieldPatch class just has FieldName & Value properties, and a Patch()-helper method to set the value for named field on a Entity. Would have been much more difficult without the "Fields" collection on an Entity
Also I already solved my issues with changes in an object graph, thanks to the ObjectGraphUtils class (are you aware that in the help, this class is mentioned a few times, saying that the full explanation of it is in the reference manual, but it's actually not there - at least I couldn't find it)