他の開発者やアーキテクトが、特定のサイト向けにアプリケーションの特定の領域をカスタマイズする際のさまざまな方法について読むことに興味があります。顧客が実装した前処理と後処理、同じことを行うイベントへのコールアウト、ビジネス ロジック メソッドのオーバーライドを可能にし、プラグ可能なモジュールによる戦略、データ構成可能なプロセス (ルール エンジン、スクリプトなど) を使用します。
リストはまだまだ続きますが、私は、誰が何を使用したか、これらの各アプローチの長所と短所、および他にどのようなアプローチがあるかを尋ねています。
これは、これらのカスタマイズに対応するために顧客固有のコード ブランチを作成しないことを前提としています。
MS は、.NET でこれを行うための 2 つの異なるフレームワーク (Managed Extensibility Framework と System.Addin) に取り組んでいます。
おそらく、アプリケーションが拡張性を公開する最も一般的に使用される方法は、実行時の型解決と組み合わせた依存性注入/制御の反転によるものです。つまり、コンパイル時に特定の実装にバインドするのではなく、実行時に外部エンティティにインターフェイスの実装を「注入」させます。IRepository が自社によって作成されたものであるか、サード パーティによって作成されたものであるかは、コードには関係ありません。インターフェイスに対してコーディングし、DI/IOC フレームワーク(このリンクは .NET フレームワークの優れた概要を提供します)を使用することで、アプリケーションを簡単にカスタマイズできるようになります。
私はすべてをモジュール化して構築し、顧客の要求に応じてプログラムに追加する傾向があります。これを顧客が制御できるアプリケーション設定と組み合わせて、モジュールを自分で追加および削除できるようにすることができます。その場合、デフォルト構成を設定するだけです。
1 つの方法は、スクリプト言語 (Python と JavaScript が一般的であるようです) を組み込み、スクリプト拡張機能を介して API のかなりの部分を公開することです。アプリケーションの一部をスクリプト言語で実装する方が簡単な場合もあります。
優れた組み込みスクリプト言語 ( Luaはまさにこのために作成されました!) からアクセスできるモジュールのライブラリとしてアプリを作成すると、ユーザーだけでなく、非常に多くの柔軟性が得られることがわかりました。でも自分のためにも。
私が扱っている製品の場合、特定の顧客のサービス グループによって、または時には顧客自身によって構築されたカスタマイズは、(私たちが作成したものについて) チームの他のメンバーと共有され、多くの場合「製品化」されます。以降のリリースで。
[ほぼ] フル アクセスの API をサポートしています。この API を使用すると、[ほとんど] GUI で実行できるすべてのことを自動化された方法で実行できます。
カスタム スクリプトを作成し、それを共有することをお勧めします。公式にサポートされているか、コミュニティ ツールのままであるかに関係なく、拡張機能を通じて製品の利用可能な用途を拡大することは、顧客ベースの間で好意を生み出すのに役立ちます。
私たちが構築するカスタマイズの場合、最初の作業は特定の顧客に請求されますが、他の場所で迅速に実装できるため、現在および将来のユーザーは製品をより柔軟に使用できます。