Применение принципа инверсии зависимостей с моделью поставщика ASP.NET

Question

У меня есть приложение, которое использует обработку IPaymentService для обработки платежей по кредитной карте. Соответствующая реализация (CreditCardPaymentComponent или CheckPaymentComponent или что-либо еще, что реализует интерфейс IPaymentService) вводится в приложение посредством PaymentProvider с использованием ASP.NET Provider Model.

Нам также нужны эти компоненты для повторного использования для различных приложений, которые могут не иметь доступа к PaymentProvider.

Вопрос в том, где положить интерфейс IPaymentService? Он не может быть внутри приложения, потому что есть несколько приложений, которые должны использовать эту услугу. Он не может быть внутри службы, потому что есть несколько служб, которые реализуют этот интерфейс. Я не люблю помещать интерфейсы в свой собственный проект, потому что тогда мне приходится добавлять ссылки везде. Есть ли другое решение?

EDIT: Чтобы уточнить, точку с помощью поставщика модели так мы можем поддержать других разработчиков, чтобы они могли написать, например 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 (или какой интерфейс подходит для этого приложения).

Если у вас несколько приложений, возможно, вам придется дублировать эти адаптеры и интерфейс. Это недостаток.