I have a data contract say User. It is serializable and goes across the wire. I want an Operation Contract SaveUser(). I can keep SaveUser(User user) in my service contract as an operation contract. But can I keep it inside my data contract itself as its own behavior?
Save() should ideally save itself. So as per OO principles, every data contract should know how to save itself and the details should be abstracted from the outer world.
Is this possible in WCF?
I would say no, and rightly so. Though I agree with you on the OO principles and encapsulation, WCF deals with SO (Service Oriented) principles. Think of this in terms of a CD Player and CD's. The CD Player is the Service. The CD is the Data Contract. OO principles would call for the CD to have a Play method in order to be able to play itself. But, there is a lot more to playing a CD than knowing it's data. There is the electronics, the interface to the output jacks, etc. These are all provided by the CD Player...the Service. So that is why your Service Contract has the Play method, and accepts the CD as a Data Contract telling it WHAT to play (and not HOW to play it).
EDIT after the question in your comment: No certainly (hopefully) not. The worst case is that you will have 34 Service Contracts, each with on average 6 methods. And this is only the case if you are sure that every one of the methods on each class MUST happen as a service operation. There are 2 aspects you need to consider. Aspect 1: The design of your services. Instead of 34 Service Contracts, you should group the 34 classes into a grouping that makes sense, and create 1 Service Contract per group. Eg, you may end up with an InventoryManagement Service, and a SalesOrderProcessing service and a BackOfficeOperations Service. Each of these services contain the service operations (and Data Contracts) relevant to the range of classes grouped into their domain. Aspect 2: What is happening on the client. I mentioned that you must consider whether each class's methods MUST be WCF Service Operations. There certainly is a case for having rich fully encapsulated business classes on the client. And where their operations don't need to execute as service operations, these operations execute their logic in the client domain. The question becomes how to get them to the client via a service, and here you have two alternatives: a) instantiate an instance on the client, and populate it's properties from the DataContract returned by a service operation. b) return the object directly from a service operation, as is done in a framework like CSLA (and I think DevForce follows a similar approach for returning business classes via a WCF Service). HTH