Managing WCF configuration when your service references are abstracted behind an API

Question

I have some domain logic exposed via WCF services. Rather than explicitly writing WCF proxy calls, etc. in my MVC web application, I've wrapped the WCF service references up into their own project - MyProject.BizLogic.Endpoint - and then added a reference to this project to my web app.

This is great for keeping the controller code clean and readable - Endpoint exposes an ICrmSystem interface with nicely abstracted methods like RetrieveCustomerDetails(int customerId), and then within the endpoint class that's wrapped up into a CustomerQuery DTO and fired off at a remote CustomerQueryHandler service. For isolation testing, you just mock ICrmSystem and test the controller methods against the mocked implementation.

Thing is - WCF needs lots of cryptic and delicate configuration, and at the moment I have to have the whole system.serviceModel bindings and client configurations in my web app's web.config file.

Is there a cleaner way of managing this configuration - preferably as part of the Endpoint abstraction module so the web developers don't even need to know that WCF is going on behind the scenes? Can I put a reference to the Endpoint's config file into my web app somehow? Or manage WCF configuration programatically instead of declaratively?

Thanks,

Dylan

Answer 1

It turns out you can isolate configuration sections into a separate file, which offers a nice balance between keeping the config isolated, and still allowing editing at runtime.

My Web.config now contains:

<system.serviceModel>
    <bindings configSource="services/bindings.config" />
    <client configSource="services/myservice.endpoint.config" />
</system.serviceModel>

which means the actual endpoint ports/protocols/etc. can be isolated in their own subfolder. This folder is now configured as an external (submodule) in our VCS, so that if we change a piece of infrastructure - say, move a service onto a different physical server - we can update the configuration, commit those changes, update any project with a dependency on those configuration sections, and avoid having to manually update config files in multiple deployed apps.

Only caveat is that IIS won't detect changes to these files as it does with the main Web.config, so after modifying one you'll either need to touch web.config or restart the Web app. Other than that, it works quite nicely.

Answer 2

Keep it in the config. I've been saved too many times by being able to instantly point services elsewhere or add new behaviors on the fly too many times to count. Coded = Compiled = Harder to Change