プロバイダパターンの使用 - 複数の抽象クラス

Question

プロバイダパターンを使用して関連するプロバイダのグループを作成しました。今私に与えられた新しい要件のために私のプロバイダを強化したいと思います。プロバイダは、当社のWebサービスと統合する多数の顧客のために作成されました。今では、同じ顧客の一部がウェブページを使用して私たちと統合したいと考えています。私たちのWebページを見れば、フロントエンドロジックはもちろん違いますが、プロバイダロジックの半分は同じになります。だから私はプロバイダとのWebページの統合を処理するために、特に顧客のプロバイダで別の抽象クラスを追加することを考えていた。私は新しいプロバイダ名と一緒にXMLWebPageBaseProviderを指す別のプロバイダセクションを定義するapp.configを今すぐ

//Same Customer provider dll  
//Methods defined for handling web service integration 
public abstract class XMLBaseProvider : ProviderBase 


//Methods defined for handling web page integration logic 
public abstract class XMLWebPageBaseProvider : XMLBaseProvider 

：ここでの可能な拡張機能を使用してコードの元です。これはうまくいきますが、この方法でコーディングするプロバイダーパターンを濫用していますか？このことを心配する必要のある懸念や悪夢はありますか？私が上記のようにこのプロバイダのパターンを実装した人はいますか？

また、Webページ統合を使用して私たちと統合するより多くの顧客を獲得する可能性があります。私は、ソリューションにますます多くのプロバイダ（dll）を追加し続ける必要があることを嫌っています。

おかげで、 DND

Answer 1

私はあなたのアイデアが良いと思います。あなたが説明したことについては、あなたのデザインはうまく動作します。しかし、解説者の一人が指摘するように、要件はJSONに拡大する可能性があります。私の経験では、異なるフォーマットの必要性は常には時間の経過とともに大きくなります。それが起こると、継承は非常に脆弱になります。クラス階層は、抽象クラスのレベルがますます大きくなります。結局、管理が難しくなります。

解説者は構成を使用することを提案し、私は同意します。戦略や訪問者のパターンは長期的にはより良いサービスになるでしょう。

アプリケーションがビジネスにとって重要でビジネスが成長している場合は、さらに進んでください。できるだけ多くのプロバイダーロジックをコードから構成ファイルまたは構成データベースに移動します。これは、要件が拡大したときに変更する必要があるコードの量を最小限に抑えるため、長期的には大きな勝利になるでしょう。コードを変更するとバグが発生する危険性があり、新しいビルドとデプロイメントなどが必要です。一部のデータを変更する方がずっと簡単で、リスクも低くなります。

この戦略は、一般にデータ駆動型プログラミングと呼ばれます。 this questionをご覧ください。