The Problem

We had a Environment class which would choose whether or not to use a webservice (it was set by a web reference) for our authentication methods by reading the host environment and if it was production or the same as the webservice would invoke it, otherwise would run the code before the migration for the webservice.

Bad design, poor testing - when working on authentication we manually forced the webservice to be in the same environment we were testing so the webservice would be called.

The Solution

  1. The Enviroment class was killed

  2. We created another webservice equals to the production but hosted on the same environment that calls it

  3. An interface that is implemented by both webservices was designed

Now we use a factory to return the right webservice for those who want to authenticate, it is possible due to the interface so if we needed to change the webservice we would only change the new interface accordly.

Different Flavours of Wrong

A person said she'd go with a key in the web.config ["I wouldn't use interfaces but the web.config"] to return the right webservice but I fail to see how it solve our problem and I don't feel comfortable to argue with/ask her due to politics and our technical skills (newbie me).

Here are some thoughts on my mind:

  • Would her key return the correct type for those who seek authentication? If so what would be the "interface" to authenticate?

  • Would her key be a boolean? In this case I'd need to write an if-else for each authentication method to call the right webservice?

  • Would her key be a string? I guess it could have the host address so only one webservice would be used and one of its proprieties would be changed on-the-fly before calling its methods (I don't know if it is possible, btw)


The webservice were created on the IDE, we'd not change theirs auto-generated code, but as they also are partials we could implement our interfaces in different files.

I didn't find if it's possible to change the entry point of a webreference we generated automatically. The IDE writes methods it has found on that address and it acts as a proxy for the service.

The factory helped us to avoid repetitive and unnecessary code, I don't see it happening with other solutions but the string on a key.

  • 1
    Are you sure that it was instead of the factory? It seems to me that you have a factory either way, but one uses the environment name to decide which class to return and the other uses a config setting.
    – pdr
    Jun 8, 2015 at 13:01
  • your question is hard to read
    – Ewan
    Jun 8, 2015 at 14:36
  • I ended up with the same impression, @pdr
    – MVCDS
    Jun 8, 2015 at 14:38
  • @Ewan, can you point me how to make it clearer?
    – MVCDS
    Jun 8, 2015 at 14:39
  • can you cut it down to the current setup, the problem and the suggested solution?
    – Ewan
    Jun 8, 2015 at 14:46

2 Answers 2


If I understood your colleague's suggestion correctly, the solution proposed was to have a web.config key that contains a type name for the implementation class. You can use this name to retrieve the type, instantiate it (or register in DI container), and use it. I.e.:

public interface IAuthenticationBlaBla

public class WebServiceAuthenticationBlaBla : IAuthenticationBlaBla {...}
public class AnotherAuthenticationBlaBla : IAuthenticationBlaBla {...}


<add key="AuthenticationType" value="Namespace.WebServiceAuthenticationBlaBla" />

somewhere in the initialization code (using DI, Autofac in this case):

ContainerBuilder builder = new ContainerBuilder();
  • A detail that I think I haven't mentioned is that she said "I wouldn't use interfaces but the web.config", that's what get me confused - all angles I see I end up using interfaces somehow. Thanks
    – MVCDS
    Jun 9, 2015 at 14:02

Your question is very hard to read, But I think I can answer the general question. my understanding of your problem is this:

  • You have a website which authenticates users via a web service

  • You need to be able to test the website

You should ensure your setup has these things:

  • The authservice client code implements an interface.

  • You have created a Mock auth service implementing the same interface

  • You inject either the real auth service or the mock via DI

  • The DI is configured via web.config

  • The real auth service should read its end point url from web.config

this enables you to set up your test and live environments via the web.config in various different ways

Live : Live endpoint URL, Real Auth service injected

Pre Live/Test : Test endpoint url, real auth service injected

Test/Dev Machine : Mock auth service injected

  • We ended up using the factory to not touch the web.config, the factory decides wheter sould use the mock or the real service based on the request. I'll look up if I can change the end point programatically, so next time I can configure it using web.config. Thanks!
    – MVCDS
    Jun 9, 2015 at 14:06
  • plx mark as answer if it answered your question
    – Ewan
    Jun 9, 2015 at 14:14
  • Sorry, it's done - though @almaz only answered the first part, I feel both give me knowledge to understand what has happened better
    – MVCDS
    Jun 9, 2015 at 14:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.