views:

144

answers:

2

I want to build a WCF data service which should be used for CRUD operations on a database backend. In order to identify the related record of the object in the database I have to know it's primary key. I use surrogate keys in my database schema.

Is it a good practice to pass the surrogate keys to the caller, so that it is possible to identify the records in the database in subsequent calls? (Caller retrieves object, caller modifies object, caller calls WCF update method) I know that surrogate keys should normally not be used outside the database. If that is not a good idea, what other options do I have?

Any advice is greatly apreciated.

+1  A: 

Yes, your solution is totally adequate. It's the simplest way to map CLR objects to persistent entities. Moreover, your services' consumers may find this unqiue identifier useful when programming UI, for logging purposes etc.

I'd go this way without hesitation.

Dmitry Ornatsky
Thanks for your answer.
A: 

I think this all depends on what type of data you are talking about. If you are talking about pure resource driven data, there are no issues with exposing surrogate keys. However, if this is business data you should only expose business keys. It allows disjoint systems to talk in a generic way.

Nix