How to build a WCF service that exposes your business layer ?

Question

WCF promotes good design by using interfaces and contracts etc. What baffles me is that, for example in my case if I have 2 sets of business functionality like ICustomerMgmtBIZ and IProductMgmtBiz. If these two are ServiceContracts, and I have an interface like

IBusinessService:IProductMgmtBIZ,ICustomerMgmtBIZ

and implementation class BusinessService. I see that BusinessService class will be having too much implementation. The workaround I have been using so far is by implementing partial classes.

So bluntly put, can a WCF service have only 1 implementation and 1 service contract ??

Answer 1

Bluntly put, no - sort of - yes, but. Any workaround is non-optimal and involves using an "IBlank" as a master WCF interface (where your interfaces derive from IBlank), and two endpoints, one implementing IProductMgmtBIZ and the other implementing ICustomerMgmtBIZ. I don't have my dev machine in front of me, this might involve some other overrides. So, at the WCF level you're screwed unless you want to have two WCF ServiceHosts (which is perfectly reasonable).

In short, the workaround is inelegant. Its easier to have two WCF endpoints on the same port with a different extension.

Answer 2

No, it is possible to implement more than one Service contract on a WCF Service type (the class that is attributed with the ServiceBehavior attribute), since it is just a matter of having the class implement multiple interfaces. If you are using any of the Visual Studio templates or other kinds of code generators, this may not be immediately clear. However, although you can implement more than one Service Contract interface on a Service type, it does not do you much good if you need the service, presumably a singleton in this case(?), to behave as one service. IBusinessService implies that you need all of the service's functionality to be callable from one client proxy, so that all operations may operate in the same logical session (similar to ASPX web session). If that is not the case, then you are free to define individual proxies for each contract interface, but that will also require that you support one endpoint for each contract.

Is it an absolute requirement that you can only have on WCF ServiceHost instance for your implementation? What factors are influencing your decision?

By the way, partial classes do not trouble me anymore. The idea of splitting out code into multiple files now seems rather natural. For example, storing partial classes in files like ServiceType_IProductMgmtBiz.cs and ServiceType_ICustomerMgmtBIZ.cs seems natural enough, in addition to storing the core logic in ServiceType.cs.

Finally, the following question might be of use... http://stackoverflow.com/questions/470726/wcf-and-interface-inheritance-is-this-a-terrible-thing-to-do/474439