1

どちらに進むか決めるのに苦労しています...
このアプリケーションは、1 つの基本プロジェクトとアプリケーション用の 1 つのプロジェクトで構成されています。アプリケーション プロジェクトには、特定のシステム、システム アプリケーションを対象とするコードが含まれています。

基本プロジェクトは、各システム固有のアプリケーション プロジェクトが実装する抽象メソッドを含む抽象クラスです。
問題は、システム アプリケーション プロジェクトには顧客固有の調整が含まれる可能性があることであり、このコードをシステム アプリケーション アセンブリに入れたくありません。

システム アプリケーション アセンブリを書き直さずに顧客固有のコードを追加できるかどうか、どこから始めればよいか、または将来のために安全で維持しやすい方法でこれを達成する方法がわかりません。

基本プロジェクト (dll) を 1 つ、システムごとに 1 つのシステム アプリケーション プロジェクト (dll) を用意し、顧客固有の調整を 1 つの顧客固有のプロジェクト (dll) に入れるという考え方です。
Rob.Core.dll
Rob.Application.BigSystem.dll
Rob.Application.BigSystem.Customer.BigCompany.dll

Rob.Core.dllは基本抽象プロジェクトです。
Rob.Application.BigSystem.dllは、システム固有のプロジェクト ( BigSystem ) であり、Rob.Core.dllから派生します。
Rob.Application.BigSystem.dllは、現在の顧客であるBigCompanyに独自の調整があるかどうかを確認し、そうである場合は、メソッドのオーバーライドまたはオブジェクトの拡張、追加のフィールドを含む可能性があるRob.Application.BigSystem.Customer.BigCompany.dllアセンブリをロードします。等

さて、要約する時間です...
ここでどちらに進むべきかわかりません。1つの基本プロジェクト(要約)を作成し、各システムから特定のプロジェクトを派生させることができます。これが開始方法のようです。
次に、独自の調整セットを持つ顧客ごとに新しいプロジェクトを作成し、システム固有のプロジェクトのすべてのメソッドをオーバーライドします。
問題は、実行時に実行されるプロジェクトはどれかということです。システム固有のプロジェクトですか、それともお客様固有のプロジェクトですか?
システム固有のプロジェクトが実行される場合、すべての顧客調整をどのようにロードする必要がありますか (存在する場合、すべての顧客が固有の調整を取得するわけではありません)。

これは非常に大きな質問ですが、アーキテクチャを書くのに役立つヒントを期待しています。

よろしく
ロバート

4

1 に答える 1

1

あなたが言ったことから、私の2つの提案:

プロジェクトではなく、タイプに焦点を当てます。「プロジェクト」は、使用可能な型でいっぱいのアセンブリを作成する方法にすぎません。プロジェクト自体は何も継承せず、サブクラス化も許可しません。顧客向けにカスタマイズされていますか?このカスタマイズはどのように行われますか?

それらを理解したら、依存性注入または拡張性フレームワークを調べることをお勧めします。試すのに適した DI フレームワークはNinjectです。優れた拡張性フレームワークはMEFです。

顧客固有の方法で型を常に提供する必要がある場合は、おそらく DI に注目する必要があります。型がデフォルトの動作に対するオプションの拡張となるものである場合、MEF のような何らかの形式のプラグイン システム/拡張システムを実行するだけの方が簡単な場合があります。

于 2009-06-08T16:29:14.223 に答える