ASP.NET提供者模型中依賴倒置原則的應用

Question

我有一個使用IPaymentService來處理信用卡付款的應用程序。 適當的實現（ CreditCardPaymentComponent或CheckPaymentComponent或其他任何實現IPaymentService接口的接口）由PaymentProvider使用ASP.NET Provider Model注入到應用程序中 。

我們還需要這些組件可以重用於可能無法訪問PaymentProvider不同應用程序。

問題是在哪里放IPaymentService接口？ 它不能在應用程序內部，因為有多個應用程序需要使用該服務。 它不能在服務內部，因為有多個服務實現此接口。 我不喜歡將接口放在他們自己的項目中，因為那時我必須在任何地方添加引用。 還有其他解決方案嗎？

編輯：為了澄清，使用提供者模型的關鍵是我們可以支持其他開發人員，因此他們可以編寫例如CustomPaymentComponent來實現IPaymentService ，它可以與我們的應用程序無縫IPaymentService 。 我傾向於@Frazell的回答，但我只是想知道將IPaymentService與PaymentComponent放在同一個程序PaymentComponent是否有任何不利之處？ 如果你必須為這個系統開發一個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 （或哪個接口適合該應用程序）。

如果您有多個應用程序，則可能會被迫復制這些適配器和接口。 這是缺點。