3

IPaymentServiceを使用してクレジット カードの支払いを処理するアプリケーションがあります。適切な実装 (CreditCardPaymentComponentまたはインターフェイスCheckPaymentComponentを実装するその他のもの) は、 ASP.NET プロバイダー モデルを使用しIPaymentServiceてアプリケーションに挿入されます。PaymentProvider

また、これらのコンポーネントは、 にアクセスできないさまざまなアプリケーションで再利用できるようにする必要がありますPaymentProvider。

IPaymentService問題は、インターフェースをどこに置くかです。サービスを使用する必要があるアプリケーションが複数あるため、アプリケーション内に配置することはできません。このインターフェイスを実装するサービスが複数あるため、サービス内に配置することはできません。インターフェイスを独自のプロジェクトに配置するのは好きではありません。参照をどこにでも追加する必要があるからです。別の解決策はありますか？プロバイダー モデル

編集:明確にするために、プロバイダー モデルを使用するポイントは、他の開発者をサポートできるようにすることです。たとえば、CustomPaymentComponentどの実装を実装IPaymentServiceし、アプリとシームレスに動作するかを書くことができます。私は@Frazellの答えに傾いていますがIPaymentService、sと同じアセンブリを配置することにマイナス面があるかどうか疑問に思っていPaymentComponentますか? このシステムの を開発する必要があるとしたらCustomPaymentComponent、何が最も理にかなっていますか?

4

2 に答える 2

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 に答える
2

インターフェイスと実装コードを必要な場所で参照する必要があることから逃れることはできません。支払いコードを多くのアプリケーションで再利用できるようにする必要がある場合は、別のライブラリ (dll) に分割して適切にパッケージ化します。

追加のアセンブリの管理は、唯一の代替手段であるコードの複製に頼るよりもはるかに簡単です。重複は絶対に避けなければなりません。

全体的に何をしているかによります。インターフェイスと基本実装を同じアセンブリ (支払いアセンブリなど) で提供し、DI を使用して、エッジ ケース シナリオで必要な実装を交換できるようにします。

于 2013-04-06T05:15:20.180 に答える