Services act on business objects, but are not business objects.
Thus, customers, orders, and products will be contracted with data, not service contracts.
These are the actions that you perform on these data contracts that make up your service contract, and the actions that you disclose in essence may or may not be what the object can do.
If, as I think, you can ask, each object has common functionality (for example, CRUD operations), then yes, you must have a separate service contact for the CRUD service for each object (CustomerCRUDService, OrderCRUDService, etc.), since Web site services do not support method signature overloads.
(From comments)
There are several ways.
1) Contracts for composite services: for example, I have a service that implements WSTransfer - this actually consists of two service contracts: IWSTransferResource and IWSTransferFactory. In turn, I have an IWSTransfer service contract that simply implements these individual contracts - the IWSTransfer open interface: IWSTransferResource, IWSTransferFactory
2) But you donβt even need to get complicated, the implementation in WCF can implement several service contracts - MyServiceImpl: IMyContract1, IMyContract2. However, a separate endpoint is required for each contract, because the endpoints are for service contracts, not implementation classes.
source share