3

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

我们还需要这些组件可重用于可能无法访问PaymentProvider.

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

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

4

2 回答 2

2

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

管理额外的程序集比诉诸代码复制要容易得多，这是唯一的选择。必须不惜一切代价避免重复。

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

于 2013-04-06T05:15:20.180 回答
2

解决方案其实很简单：

使用适配器模式。

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

class CreditCardPaymentServiceAdapter : IPaymentService 
{
   private CreditCardPaymentService service;

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

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

该适配器本身将不包含业务逻辑，而只会映射/转换/适应真实CreditCardPaymentService并暴露IPaymentService（或适合该应用程序的接口）。

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

于 2013-04-06T12:49:46.310 回答