How to design WCF Contracts?

1
votes

We are designing a WCF layer which can be invoked either by a Asp.Net or a WinForm application. Our Application contains too many Entities. We have basically two choices.

  1. If we design WCF Contract around these entities then we get too many Contracts e.g IPartyService, IUserService, IPaymentService etc. So, I may end up with 30-40 Contracts?

  2. One huge contracts with around 100 operations?

What are the pros and cons of each approach or is there a better way?

1
.netwcfweb-servicesdesign-patternssoa
What kind of methods do you want to implement - CRUD or business logic? – Daniel Brückner
Its mostly CRUD but can also have business and validation logic. – Amitabh
40 entities with 4 CRUD operations each is not hard to implement with generics but I would actually think about only creating 4 operations and passing the type as a parameter. May this work for you or are the requirements per entity to different? – Daniel Brückner
What is it about "too many entities" that you don't like? Do you feel they would cause problems on the client or the server? – John Saunders

1 Answers

1
votes

The first approach makes the entities more organized. The downside is that you have too many endpoints. Your client needs to initialize multiple service instance to perform a operation (for example: You need to initialize the customer service and the order service to save customer and order details. - But this could be prevented if you implement business process logically on each service\operation).

The second approach is quite overwhelming to the client app developer. The advantage is performance since everything is on a single contract, it will be easier for you to optimize the code and minimize service calls.