WCF - Single Web Service Endpoint Using Partial Classes

A project I am working on requires a structure as such:

{BasePrefix}/Application/{id}/Security/Users/{userId}
{BasePrefix}/Application/{id}/Objects/{objectId}
etc.

Application.svc would be end up being my WCF Web Service. I tried to convince them to do:

{BasePrefix}/Security/Application/{id}/Users/{use开发者_StackOverflow中文版rId}

This would allow me to have multiple WCF Web Services as Security.svc, Objects.svc, etc.

They still want it all under application so instead of throwing all my service methods into a single file, I wanted to break it out by functionality and use partial classes to combine it all into one resource.

I saw an article about how to do this here: http://www.meineck.net/2008/04/wcf-hosting-multiple-wcf-services-as.html

The developer in that article is working with a Net TCP binding, however, so I am not sure if this will work with a WebHttpBinding and how IIS will handle the multiple resources.

Has anyone done this? Is the article I linked a good resource? Or is there a better alternative method to achieve the same results?

The methodology in the linked article is sound, and will work for bindings other than netTcpBinding (including webHttpBinding, wsHttpBinding and so on).

However, I believe what you are trying to do is use a URL rewriting scheme (probably using the UriTemplate property), which is subtly different from what that article actually talks about. It is referring to the creation and implementation of multiple interfaces, by the same service, and mapping each interface to its own endpoint.

The approach does not work with a single endpoint. So if your endpoint is {BasePrefix}/Application, that can only be mapped to one interface (say IApplicationService) in the configuration.

In your case, I don't think you'll be able to go the multiple-interface route because you need to have just one endpoint. So you'll still need a single monolithic interface with all of the methods (ugly), but you could in theory use partial classes to split up the implementation of those methods into logical groups. It's better, but not exactly ideal.

You were on the right track with your original assessment. If your scheme looked like:

{BasePrefix}/Security/Application/{id}/Users/{userId}
{BasePrefix}/Repository/Application/{id}/Objects/{objectId}

Then you would be able to use either of the approaches - either have multiple services, or have a single service that implements multiple interfaces and hosts multiple endpoints.

What the code/configuration in that article is really designed to do is enable a single service instance to host multiple endpoints. The main reason to do this is if you would otherwise have to duplicate a lot of code between services. Unfortunately that's not your goal here, so you will either have to push harder for your proposed URI scheme, or deal with a monolithic service contract (interface) and do the best you can to keep the implementation clean through #region directives and/or partial classes.