title: Send partial objects with only changed fields to Web API and Entity Framework
body: <p>WebApi and EF POCOs work really well together. An issue I've been thinking on is that some objects can become really quite large over time. They can have lots of properties that map back to columns in the database. With these objects it would be rare to ever update more than one or two fields at a time so it begs the question, why require all the fields to do the full trip back from client to server to database.</p>
  
  <p>Some JavaScript frameworks provide the option as to whether to send all fields or just changed ones back to the server so client side is clean and simple.</p>
  
  <p>Server side is a little bit more of a challenge from what I see. The serializer will step in and try to map some json or xml to a type. JSON.NET for example handles missing values well provided the corresponding properties in the object are nullable.</p>
  
  <p>Reattaching the deserialized model back to entity framework on the other hand is where things get tricky. The default WebApi template for a controller does it in one line:</p>
  
  <pre><code>db.Entry(user).State = EntityState.Modified;
  </code></pre>
  
  <p>This obviously sets the whole object to modified. It's of course possible to set individual properties to modified rather than the whole object and I would assume this means EF is a little more clever and only sends the modified properties back in the SQL UPDATE.</p>
  
  <p>So the problem here is, how do I know what properties are updated? I only get a object back in my controller method so I cant ask the serializer what properties it pulled in (even if that was possible for a given serializer).
  If I have a list of properties then I could set current values with their state to modified in EF and hopefully that should result in my clean db query.</p>
  
  <p>The other perhaps more obvious option is to first retrieve the object I want to update from a database, and modify only the changed properties one by one on the retrieved object or if EF has support for it, perhaps I can pass it the unattached object and have it do this itself. This isn't as desirable an option as it does mean a whole database read where the whole point of the exercise is efficiency. What we would be doing is trading the clients http efficiency and bandwidth for hit on server to db efficiency.</p>
  
  <p>So to me it seems if I want to do this on the server, I'm between a rock and a hard place. WebApi and EF do most of the work, but at the cost of flexibility. I'm looking for options or angles that I haven't mentioned in hope of a simple solution that doesn't throw away one of these two great technologies.</p>