WCF Contract for Field Level Update

Question

I am developing an application that performs some CRUD operations through the WCF service. The read method returns the full object, the update is performed through an outdated system, and only the changed values ​​should be updated.

What is the best way to design a data contract for this scenario without just sending a dictionary of key-value pairs?

Answer 1

The only thing I can think of is to make your component durable - i.e. save your state in a file or database. Thus, in the update, you can compare the previous state with the transmitted state. I'm not sure if this is a good way to go, as it will lead to more overhead than just passing key-value pairs.

From the outside, it may look more CRUDY or something else, but from a practical point of view, it might be better for you to simply convey some guidance as to which values ​​have changed.

Answer 2

In case this helps, I’m not sure exactly what you are looking for, though ...

Only fields that are not null are valid in the update request.

Also, wrap any non-empty types in the structure with a null value.

As an example...

Update( Nullable<int> orderNumber, Nullable<DateTime> orderDate, Nullable<bool> isComplete ) { if( orderNumber != null ) databaseRecord.OrderNumber = orderNumber; if( orderDate != null ) databaseRecord.OrderDate = orderDate; if( isComplete != null ) databaseRecord.IsComplete = isComplete; } 

Answer 3

the best way to do this is with a property dictionary, just think of your objects as a dictionary of the name and value of the property. save all changes in a list and pass an incomplete dictionary with all changed properties.

I think this is the best design,

If you want to avoid this project, send the entire object with some list of changed properties. (to save transport u can put null in other properties)

If you do not want to change the signature of the service contract, you can click the names of the changed properties in the header

Answer 4

I had two ideas on how to achieve this;

• Ask the client to send both the source object and the changed object completely, the service will then find out what properties have been changed.

• Use a template similar to Nullable, allow its modification using the IsModified flag and the NewValue property of type T. Each DataContract property will be of this type, the service can check the IsModified flag when performing the update.

The inherited sytem we use has an api that accepts String.Empty to identify unmodified fields, '?' A character is used to indicate an empty line update. I really don't like this, the api user is forced to read the documentation, and if you really want to save '?' You can not. I want our webservice api to be more explicit.

Answer 5

You can use the DataSet to save your changes. Call your record as a DataSet, then assign some record values. DataSet.Tables [0] .GetChanges () will provide you with the columns that have changed.

Answer 6

You can leave a contract with the data yourself and renew your service contract. Simply specify the required fields for the method as properties in the service contract. Any consumer application that uses this service must be updated if the service contact changes, but the consumer application knows what is required to successfully update the data.

There are positive and negative sides to this method, but I use it when the method I write does not require a full data contract.

- Edited for spelling error -

Answer 7

Looking at your requirements and statements, I made a few assumptions before starting to write my vision about a possible solution:

• You use the same class to retrieve (the return type of the read operation) and update the item (input type of the update operation) in your WCF service.
• Your current implementation problem is how to use the source class (not the dictionary) and still be able to define “what has changed compared to reading” when you get the “Update” operation called by your WCF service
• You are writing a server and a client. Both are written using MS.Net.

If so, the problem is the lack of update information. The necessary information has “changed”, which can be displayed if there is a second state for comparison or should be present next to the state for updating in the background.

Since you only have a “back-end state” (no flags) when the client sends its data to the WCF service, how do we determine what has changed? Obviously, we want to prevent another “read” roundtrip in order to get the current state of the server and start comparing.

Sending the initial and altered state from the client to the server is a possible, but difficult decision. In addition, the client is not interested in this information, the server.

Adding this all guesses that changing the type of the input parameter of the Refresh operation is the easiest way. Create a decorator class that adds the dirty bit behavior to the original entity. Use this new class as an input to the Refresh operation. You will then have availability on the server to check this dirty bit next to the full status message by the client. The main change on the client side is that the object required for the Update operation is no longer the same as that provided by the Read method. To increase this pain, I would probably create a decorator class that added the necessary "dirty bit" processing. This requires only changing the object, supporting the signature of the interface for the client (very few code changes).