views:

96

answers:

2

If you don't want to expose the ID of a domain object to the client of a WCF service, you would obviously not put an ID property in the DataContract, right? But then, when the client calls the save method on your service, how do you know it's a new object, or an existing one that was modified?

With NHibernate you can use SaveOrUpdate and it will check the Id and the unsaved-value, but when you receive the DataContract without the ID, you've no way of knowing if it's a new record to save to the database, or an existing record to update.

How would you solve this?

+1  A: 

A Data Contract represents whatever you want it to represent.

If you don't want to expose the actual ID, then you can expose an alternate key of some sort, then look up the real entity by this alternate key. For instance, you could expose an ID of type Guid, and maintain your own dictionary or lookup table mapping Guid to the actual ID. Of course this now introduces some state you'll need to maintain.

John Saunders
+1  A: 

I would argue against your logic - the entity you're exposing back to the client should have it's unique ID - that's your only "safe" handle to uniquely identify and find your entity.

The client app should definitely not show the system-internal unique ID - but it does need to travel between service and client, in order for the service to know which object to operate on when an update or delete request comes back from the client.

Marc

marc_s