如何在运行时使用外部API的伪类(可配置)?

时间:2013-07-12 01:02:42

标签: c# asp.net design-patterns inversion-of-control integration

我需要从外部API获取数据,只能通过VPN访问。 开发/测试机器无法始终连接到VPN。

期望的行为是使用两种不同的实现(一种调用实际的外部API,一种充当真实的东西,但返回虚拟数据)。将使用web.config中的标志配置要使用的实现

我已经尝试了IoC容器StructureMap和Unity,他们都完成了这项工作,但它们似乎只适用于MVC,我正在寻找一种也适用于Web表单的通用解决方案。而且,将它们用于这个孤立的设计问题是不是有点过分了??

这种特定情景是否有设计模式或最佳实践方法?

2 个答案:

答案 0 :(得分:1)

IoC /依赖注入听起来像是正确的方法,但是对于简单的场景,您不一定需要容器。关键是让依赖于API的类引用接口IAPI,并将实际的实现RealAPIFakeAPI传递给它。

public class SomeClass
{
    private readonly IAPI _api;

    public SomeClass(IAPI api)
    {
        _api = api;
    }
}

现在,您应该可以通过将另一个对象传递给MyClass来轻松切换实现。理论上,当您使用IoC方法时,您应该只需要在应用程序的顶层将接口绑定到实现一次。

答案 1 :(得分:0)

  

将它们用于这个孤立的设计问题是不是有点过分了??

他们可能是。那些IoC容器只在你编写松散耦合的代码时才能帮助你。例如,如果你没有按照SOLID原则设计你的类,那些框架可能只会妨碍你。另一方面,哪个开发人员不想编写松散耦合的代码?换句话说,IoC container solves a problem you might not have but it's a nice problem to have.

  

StructureMap和Unity [...]似乎只适用于MVC

这些ioc框架可以在任何类型的应用程序中使用(只要它以松散耦合的方式编写)。某些类型的应用程序需要更多的工作来插入框架,但它始终是可能的。 StructureMap和Unity可能只有MVC的集成包,在ASP.NET Web Forms中也很容易使用它们。

  

是否有针对此的设计模式或最佳实践方法   特殊情况?

您要找的是Proxy pattern,也许是circuit breaker pattern