动态命名空间切换 [英] Dynamic Namespace Switching

问题描述

我正在尝试将Web服务封装在几个第三方Web服务上。为了这个问题，我们将与其中两个工作：

I'm attempting to put a web service wrapper around several third-party web services. For the sake of this question, we'll work with two of them:

1. OrderService


2. AddressService

这两个服务都具有在不同命名空间中定义的相同对象：

Both of these services have the same object defined in different namespaces:

1. OrderService.AuthenticationParameters


2. AddressService.AuthenticationParameters

I希望能够创建一个能够在命名空间之间检测/切换的基类。例如：

I was hoping to be able to create a single base class that would be able to detect/switch between namespaces. For example:

public abstract class BaseLogic
{
    internal BaseLogic()
    {
        /* Initialize authParams */

        //Switch out / detect namespace here
        this.authParams = new OrderService.AuthenticationParameters();
        this.authParams.accountName = "[MyAccountName]";
        this.authParams.userName = "[MyUserName]";
        this.authParams.password = "[MyPassword]";
    }
}

我看过几个类似的问题。或者他们不适用于我的情况，或者我无法理解他们。

I've seen several similar questions. Either they don't apply to my situation, or I'm incapable of understanding them.

问题：我正在尝试实现可能吗如果可能，我是否会复杂化？

Question: Is what I'm trying to achieve possible? If it's possible, am I over complicating things?

附加信息：最后，共有两个以上的共享对象的服务。供应商为其提供的功能的每个分支机构提供单独的服务URL。

Additional Info: Eventally, there will be more than two services that share this common object. The vendor provides a separate service URL for each branch of functionality they provide.

推荐答案

有很多解决方案。

• 让您的服务代理类实现您自己的界面来公开方法，然后简单地使用反射来构建一个类型。


• 将这两个服务包含在另一个公开方法的类中，并引用 两种服务，然后只需提供一个切换参数即可确定使用哪种方式。 li>
  
• 通过自己的界面抽象使用服务，并明确地对每个服务进行编码（见下文）。

• Have your service proxy classes implement your own interface to expose the methods, and then simply use reflection to build a type.
• Wrap both services in another class that exposes the methods and has a reference to both services, then simply provide a switching argument to determine which to use.
• Abstract the use of a service via your own interface and have classes coded against each service explicitly (see below).

或者如果你想玩动态和鸭子打字，这似乎是有效的：

Or if you want to play with dynamic and duck typing, this seemed to work:

namespace ConsoleApplication42
{
    class Program
    {
        static void Main(string[] args)
        {
            Type t1 = Type.GetType("ProviderOne.AuthService");

            dynamic service = Activator.CreateInstance(t1);

            Console.WriteLine(service.GetUsername());

            Type t2 = Type.GetType("ProviderTwo.AuthService");

            service = Activator.CreateInstance(t2);
            Console.WriteLine(service.GetUsername());

            Console.Read();
        }
    }
}

namespace ProviderOne
{
    public class AuthService
    {
        public string GetUsername()
        {
            return "Adam";
        }
    }
}

namespace ProviderTwo
{
    public class AuthService
    {
        public string GetUsername()
        {
            return "Houldsworth";
        }
    }
}

请记住，他们都铰链对于具有相同签名的两个服务。

Bear in mind they all hinge on both services having the same signature.

对于未来的其他服务，这真的取决于。我从来没有真正遇到过需要从一个服务动态切换到另一个服务，以获得稍微不同的行为来实现同样的事情。

As for the other services in future, it really depends. I've never really encountered a need to dynamically switch from one service to another to get slightly different behaviour in achieving the same thing.

也许这应该是从你的应用程序的驱动？而不是选择适合的服务，只需实现具有这种变化行为的类的两个版本 - 在其上放置一个通用界面，并确定 您的 类中的哪个类在运行时使用。该类本身将直接针对一个服务编码。

Perhaps this should be driven from your app's side? Instead of a service being chosen to suit, simply implement two versions of the class that has this changing behaviour - put a common interface on it, and decide which of your classes to use at runtime. The class itself will then be coded directly against one of the services.

interface IGetUsername
{
    string GetUsername();
}

class UsernameViaProviderOne : IGetUsername
{
    public string GetUsername()
    {
        return new ProviderOne.AuthService().GetUsername();
    }
}

class UsernameViaProviderTwo : IGetUsername
{
    public string GetUsername()
    {
        return new ProviderTwo.AuthService().GetUsername();
    }
}

然后，决定坚定地在您的客户端代码中，并删除反思/动态打字的需要：

Then the decision is firmly in your client code and removes the need for reflection/dynamic typing:

IGetUsername usernameProvider = null;

if (UseProviderOne)
    usernameProvider = new UsernameViaProviderOne();

...

为了努力，你可以永远得到SOA和创建另一个服务，您的应用程序与其聚合其他两个服务。那么至少你的客户端代码看不到大量的不同的服务，只能一个。

To labour the point, you could always get very SOA and create yet another service that your app talks to that aggregates the other two services. Then at least your client code doesn't see the huge number of different services and talks to just one.

这篇关于动态命名空间切换的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！