サーバーベースのアプリケーションのいくつかのアーキテクチャの問題を熟考するのに苦労した後、目標を達成するにはシングルトンを使用する必要があると感じています。純粋に次の理由からです（私の匂いを正当化します）：
- 高価なオブジェクトをコール スタックの奥深くに渡す必要がない
- 任意のコンテキスト内でシングルトン管理オブジェクトに対して機能を実行できます。(多くのコードが既に存在するため、それ以外の場合は機能するコードの膨大なチャンクを書き直すつもりはありません)
それとは別に、シングルトンは別の問題を示唆しています。私のサーバーベースのアプリケーションは、基本的に、サーバーの複数のインスタンスを呼び出すことができるクラスを持つ DLL です。サーバー インスタンス クラスには、シングルトン管理オブジェクトが含まれています。通常、これは Windows サービスによって管理されるため、サーバー:マシンの比率は 1:1 になります。
したがって、次のように表示できます (ここで、-> は 1:1、=> は 1:多):
MACHINE -> ServiceHost (Windows サービス?) -> サーバー インスタンス -> シングルトン管理オブジェクト
ただし、ビジネスの必要に応じて複数のサーバーを起動できるサービス ホスト (Windows サービスまたは Win32 アプリケーション) を必要とする SaaS モデルを許可したいと考えています。したがって、物理マシンは、複数のサーバー インスタンスを実行する単一のサーバー ホストを実行できます。
どちらになりますか (ここで -> は 1:1、=> は 1:多):
MACHINE -> ServiceHost (Windows サービス?) =>サーバー インスタンス ->シングルトン管理オブジェクト
問題は、これらのシングルトンがサーバー間で共有されることです。これは起こり得ません。シングルトンは、サーバー インスタンスと 1 対 1 である必要があります。
これらのシングルトンから離れることはできないと仮定すると、サービス インスタンス クラスを個別のプロセス/メモリ空間として呼び出すことによって、これらのサーバー インスタンスを互いに分離することは可能ですか?
サーバー インスタンスごとに 1 つずつ、複数の EXE を起動する (および管理に WCF を使用する) 必要があることだけは想像できます。これは明らかにあまり良くないでしょう。