2

I'm building a set of Console applications which all need to reference a web service. I have a class library which contains much of the shared functionality of these applications, including the web service (which has been added as a service reference). I know that the "correct" way to handle this is to copy the block from the class library's app.config to each console app, but that causes maintenance headaches. I've also found the alternative of using a shared app.config file, with a reference to it from each app's config. That's better, but still not great - it still involves manually configuring each new app, and requires me to make sure the shared config file is in a place that all the apps can access.

What I'm looking for is one of three things (in declining order of satisfaction):

  1. A way to encapsulate the whole service, and everything necessary to access it, into the dll that's produced from the class library.
  2. A way to automatically copy the relevant config information into each console app's build directory (such as a post-build script).
  3. An explanation of why neither of the prior two is feasible. (In which case I'll go with the shared config)

Any advice?

Bobson
  • 13,498
  • 5
  • 55
  • 80
  • `encapsulate the whole service` ? – Nix May 16 '11 at 16:37
  • Pretty much. The console applications don't need to see that the service exists at all. They just need to use the classes in the library to do their thing. The fact that part of what happens in those classes involves a web service is irrelevant to them and may change at a later date. – Bobson May 16 '11 at 16:41
  • So it comes down to creating an api and adapting it to the service. You talk a lot about config files in your question, but never mention what you are trying to do with the service (that was why I was asking ;) ) – Nix May 16 '11 at 16:45
  • I'm not creating the service - I'm consuming an external one. – Bobson May 16 '11 at 16:47
  • When I say adapting it to the service I mean consuming your service. I am typing up something now. – Nix May 16 '11 at 16:47

2 Answers2

3

Honesty 2 is trivial. You can easily copy a config file to a build directory. A simple google search can give you everything you need.

For Part 1 you have options here, I would suggest simply defining the API for your service in an interface form. Then using DI to plug in the "implementation" via a dll. Its done all the time using the Adapter Pattern, and then using something like Unity, for the runtime implementation.

PSEUDO:

interface IMyServiceAdaptor {
   void SomeMethod(params );
   void SomeMethod2(params );
}

public class ServiceAdaptor : IMyServiceAdaptor{
    #psudo code
    ServiceProxyClient client  { get;set;}

    public void SomeMethod(parms){
       var convertedParams = Convert(parms);
       return client.SomeMethod(convertedParams );
   }
   ...etc

}

public class MyClient {
  [Dependancy]
  IMyServiceAgent agent { get;set;}

  public MyClient(){
     #resolve
 }

}

Concept is simple. You have an internal representation of your service(IMyServiceAdaptor). It is important that it is completely independent of the underlying proxy(service reference) calls that actually call your service. The idea is you create a friendly interface for your service and you interface with that. You always adapt the service to meet your applications interface API. This will shield you from changes on the service side, provide the interface that you can use for injection, as well as allow you to insert some additional logic to deal with failure.

Nix
  • 57,072
  • 29
  • 149
  • 198
  • I think I'll go with #2 - until you mentioned it, I didn't think of combining the "include a config file" for each app.config with a build script to copy the shared config into each. I do appreciate the answer to #1, but it's more than I want to deal with for what's mostly just a headache. – Bobson May 17 '11 at 14:25
1

After taking some time to work on other things, I returned to this issue and found a related question over here. Trond's answer to that question worked just fine for me, and was much simpler than anything else.

Community
  • 1
  • 1
Bobson
  • 13,498
  • 5
  • 55
  • 80