0

だからここに問題があります：

私のアプリケーションには、クライアントごとに異なるロジックがいくつかあります。コードを変更せずに構成できるように、これを構造化する最善の方法は何ですか。次のように、構成に appsetting を既に追加しています。

<add key="MyCalculationType" value="MyApp.Client1.Calculation,MyApp.Client1" />

私のコアビジネスロジックでは：

ICalculation abcCalculation = CalculationFactory.GetManager(); // Uses appsetting to get type

abcCalculation.Calculate(this);

クライアント固有の Calculate の実装を含めるために、MyApp.Client1 という名前の新しいプロジェクトを追加しました。

namespace MyApp.Client1
{
    public class Calculation : ICalculation
    {
        public void Calculate(Order o)
        {
            // Calculate properties of order
        }
    }
}

まだ完成していないので、出力を提供することはできません。この段階で、先に進む前に、私がしようとしていることを達成するためのより良い方法があるかどうかを知りたい. 確かにわからないことの 1 つは、ICalculation インターフェイスを配置する場所です。私のやり方では、循環参照エラーが発生する可能性があると思います。

どうもありがとう

編集

私が疑ったように、ICalculation インターフェイスがビルドを妨げています。循環参照エラーではありませんが。「シンボルを解決できません」というエラーが表示されます。

4

2 に答える 2

1

ICalculationインターフェイスはConnectorBridgeライブラリ内に配置できます。このライブラリは、外部プラグインとホスト環境とのアクセス、サブスクライブ、および通信を管理します。

アプリケーションと（たとえば）計算プロジェクトには、ConnectorBridgeへの参照が含まれています。このようにして、CalculationはICalculationインターフェースを実装し、アプリケーションは抽象化にアクセスできます。

アプリケーションにフォルダを作成します。たとえば、プラグイン を作成し、アプリの起動時に、そのフォルダのコンテンツをスキャンして、インターフェイスを実装するDLLの存在するタイプを探しICalculationます。タイプが見つかると（この特定のケースでは電卓）、タイプが作成され、将来の実行のためにアプリケーションに保存されます。

これらは単なるアイデアの集まりですが、具体的な実装には当然、はるかに多くの作業が必要です。

お役に立てれば。

于 2012-07-03T13:54:53.790 に答える
0

そのようなことを本当に行う必要がある場合は、適切なInversion of Controlコンテナを探す必要があります。NInjectは非常に強力で、非常に構成可能であるため、私は NInjectを好みます。

于 2012-07-03T13:51:37.857 に答える