具有DEV，QA和PROD版本的WCF服务

Question

First off, I did look on google and stackoverflow, but nothing seem to really meet my desires.

That said. I am using an MVC application (It could just as well be a Web Forms app) that I inherited from a previous developer(s). The current Service References point at production servers and I would like to simply point also at local dev servers. Ideally I would like to not edit the web.config file for changing from dev to prod (especially if it is for several places etc..)

Thus, perhaps there is a "best practice" for adding extra web references and being able to quickly "swap and test" the DEV references to PROD references with very little configuration changes.

Perhaps a design pattern, or an appconfig setting to facilitate this process? It certainly would be ideal to keep it loosely coupled with constructor injection of the service references. Any thoughts on how to best implement this?

Answer 1

Another option would be to add multiple endpoint configurations for the same service that point to different addresses. Then when you create a new instance of your service client you pass the name of then endpoint configuration.

ContractServiceContractClient client = 
new ContractServiceContractClient("DEV_Endpoint");

or

ContractServiceContractClient client = 
new ContractServiceContractClient("PROD_Endpoint");

And in your ServiceReference config

<endpoint address="http://localhost:7821/ContractService.svc"
          binding="basicHttpBinding" 
          bindingConfiguration="BasicHttpBinding_ContractService"
          contract="ContractServiceReference.IContractService" 
          name="DEV_Endpoint" />

or

<endpoint address="http://service.apps.com/ContractService.svc"
          binding="basicHttpBinding" 
          bindingConfiguration="BasicHttpBinding_ContractService"
          contract="ContractServiceReference.IContractService" 
          name="PROD_Endpoint" />

Then if you just create a global static string or put something in your app.config that contains the name of the endpoint configuration you want to use, then you just have to change it in that one spot and it will update across the application.

The only catch here is that you can't create an instance of your service client without passing which endpoint configuration you want to use if you have more than one endpoint configuration for the same contract.

Answer 2

what I usually do is to have all settings in the database, and we have different database connection strings (machines are different) for each environment.

in the app/web.config we simply change 1 key specifying to which environment we are pointing then everything else comes from the settings table in the database which contains different values per environment. For service references the checked-in code always and only points to localhost and at runtime the url is assigned from the settings retrieved from the db.