WCF and optimistic lock.

WCF and optimistic lock.

Old forum URL: forums.lhotka.net/forums/t/8442.aspx


Xela2200 posted on Sunday, January 31, 2010


I noticed that on the project tracker application when a response object is return like the ProjectData for instance, no property containing the timestamp value of the entity is return. Then, if I want to implement optimistic lock in my data, should I include a property with the timestamp value?

Thanks.

RockfordLhotka replied on Sunday, January 31, 2010

You are talking about Chapter 21 and the WCF service interface?

Your service interface is a contract, composed of three things:

  1. Operation contracts
  2. Data contracts
  3. Fault contracts

Combined, these contracts define the immutable contract you are providing to all applications that make use of your service.

You don't, and can't know what those applications will do or how they will work. Or even what technology will be used to create them. So a good contract will make no assumptions about the external application.

At the same time, your contract must provide the external applications with the operations and data they requires to do something interesting and useful. Obviously you can't know exactly what operations and data will be required - because you don't know what consuming apps will exist in the future - so you clearly have to make some educated guesses.

That's all background. The real question you are asking is whether you should include metastate (timestamp, IsNew, IsDirty, that sort of thing) with the data you provide. Should that be part of your data contracts?

There's no easy asnwer. Since you can't depend on external clients to consume or return such metastate reliably, you have to be extremely cautious about providing it (and consuming it). And you must consider that providing such metastate implies a higher level of capability on the part of the consuming app - you are assuming that app is written by a developer, using a developer tool. That may not always be the case, since services can be consumed by some fairly abstract tools that might be used by power users (consider SharePoint for example).

So including metastate might prevent some consumers from being able to use your service, by raising the bar too high. And it may make other consumers have a hard time working with you for the same reason.

In my view, if you do provide complex elements like metastate, you really need to provide solid documentation around your public contract. The more of that sort of thing you add to the contract, the less intuitively useful the contract becomes, and the more a consumer must rely on your human-readable documentation.

Copyright (c) Marimer LLC