ASP.NET提供者模型中依赖倒置原则的应用

Question

我有一个使用IPaymentService处理信用卡付款的应用程序。适当的实现（CreditCardPaymentComponent或CheckPaymentComponent或实现IPaymentService接口的任何其他内容）由PaymentProvider使用ASP.NET Provider Model注入应用程序。

我们还需要这些组件可以重用于可能无法访问PaymentProvider的不同应用程序。

问题是放置IPaymentService界面的位置？它不能在应用程序内部，因为有多个应用程序需要使用该服务。它不能在服务内部，因为有多个服务实现此接口。我不喜欢将接口放在他们自己的项目中，因为那时我必须在任何地方添加引用。还有其他解决方案吗？

编辑：为了澄清，使用提供者模型的重点是我们可以支持其他开发人员，因此他们可以编写例如CustomPaymentComponent来实现IPaymentService并且它与我们的应用程序无缝协作。我倾向于@Frazell的答案，但我只是想知道将IPaymentService与PaymentComponent s放在同一个程序集中是否有任何不利之处？如果你必须为这个系统开发CustomPaymentComponent，那对你来说最有意义的是什么？

Answer 1

您无法逃避必须在需要的地方引用接口和实现代码。如果支付代码必须在许多应用程序中可重用，我会将其分解为一个单独的库（dll）并对其进行适当的打包。

管理附加程序集比使用代码重复要容易得多，这是唯一的选择。必须不惜一切代价避免重复。

取决于你在做什么。我将在同一个程序集中提供接口和基本实现（例如支付程序集），并允许使用DI在边缘案例场景中交换所需的实现。

Answer 2

解决方案实际上非常简单：

  

使用适配器模式。

您根本不让组件实现该接口，而是基于该接口为每个组件实现适配器。在这种情况下，适配器和接口可以放在一起：

class CreditCardPaymentServiceAdapter : IPaymentService 
{
   private CreditCardPaymentService service;

    public CreditCardPaymentServiceAdapter(
        CreditCardPaymentService service)
    {
        this.service = service;
    }

    // Implement IPaymentService here and forward
    // to the CreditCardPaymentService.
}

此适配器本身不包含业务逻辑，但只会映射/转换/适应真实的CreditCardPaymentService并公开IPaymentService（或哪个接口适合该应用程序）。

如果您有多个应用程序，可能会被迫复制这些适配器和界面。这是缺点。