Client Server Design Question: Maintaining State On Both_问答_开发者

Thanks for taking the time to review my question!

Let’s assume that there is a web service (restful, SOAP, XML/JSON, what ever you want) and it was a service regarding puppies. A puppy, for the purposes of this question, can have two member variables. The first one is a unique ID of the puppy开发者_C百科. The other data member is “number of fleas” (Flea Count).

One of the features offered by the puppy service might be “return an object representing a puppy based on the puppy’s ID.”

How would you handle the requirement that a client application can update the Flea Count? Here are some of the ideas I've been floating to myself:

Do you let the client update the puppy’s Flea Count on the client-side and then send the entire object back to the service so its state can be updated?
Do you create a method that takes in a puppy ID and a new Flea Count in order to sync the client with the server, but don’t send anything back?
Do you create a method that takes in a puppy ID and a new Flea Count but have the service respond with the entire updated object that then replaces the existing puppy (oh no!) on the client side?
Do you create a method that takes in a puppy ID and a new Flea Count, which updates the server, but then the client must call the method associated with returning a puppy object by ID and that replaces the puppy on the client side (perish the thought!)?
Other?

Thanks.

Depends on your architechtural design--there really isn't a single correct answer:

1) This sounds like using a "Mobile Object", i.e. the whole object (logic included) can be serialized and sent across the wire. It could also be seen as a DTO (data-transfer-object) with no logic.

2) This sounds more SOA--SOA is focused on making a service offer intuitive methods which a client can consume. If the method is named something like UpdatePuppyFleaCount(puppyId, fleaCount) then it makes sense.

3) This is also SOA'ish, but really blurs the line since it's both an Update and Read operation (it would make more sense if you sent the updated Puppy object and the server responded with the committed Puppy object--the client would have to know to swap, but it's not uncommon).

4) This is really use-case dependant. If you expect to update the flea count and do nothing else with the puppy then it makes sense. If you expect to always work with the puppy after updating the flea count then it's a poor design to require the client to make two calls (webservice calls are slow).

5 - inverse of 4 (read the puppy, pass the puppy instance and new flea-count to the server, get back updated puppy): Again, this depends more on use-case. If it's likely that the Read operation will be used seperately from the UpdateFleaCount() operation (i.e. you'll don't always want to update the flea count after retrieving a puppy) then it fits well.

Expanding on my comment about "not a single correct answer"... I coined the "Silver-bullet rule" (although I'm sure someone notable beat me to it a long time ago) that in programming there is never a silver bullet; you always have to weigh the pros/cons, cost/benefit of different approaches. The key is in identifying and understanding the differences between different approaches

Each instance of puppy is maintained at the server and the service should expose methods to get and set and refresh puppycount.

Number 2, modified to return a boolean result indicating that the update was or was not successful

Here's some more questions (!).

Is the same puppy held on multiple clients ? If so, then you may need to broadcast an update to each client to refresh its puppy when there's a flea update.

Would you normally give the client an immutable object (the puppy). Can the client update the puppy and ensure it's still a valid object ? This isn't such a stupid question - clients are often given DTOs (data transfer objects) and can set fields at will. A proper object would ensure validity.

Is bandwidth important ? Can you handle publishing multiple puppies out across your network ? This is especially important if the answer to the first question is "yes".

Given the above, I would perhaps call a method on the server requesting a flea update on puppy X. The server can perform this (with associated validation), and publish out an update to all interested parties. The update would likely consist of a new puppy object (depending on your use case, you may publish out that puppy X has updated, and clients can fetch the new puppy if interested - perhaps that's an optimisation too far)