0

aspx ページを初期化するときに、StructureMap コンテナーで (OnInit 内で) 宣言して、適切なプレゼンターに挿入します。

container.Configure(x => x.For<IMyInterface>().HttpContextScoped().Use(this));

HttpContextScope は、現在のリクエストの最後にコンテナーから「this」(つまり、ページ オブジェクト) を強制的に削除する必要があります。それを証明するために、上記の行の直後に次のコードを追加しました。

IEnumerable<InstanceRef> refs = container.Model.InstancesOf<IMyInterface>();
foreach (InstanceRef r in refs)
{
  Type t = r.ConcreteType;
}

質問は：

ポストバックごとに refs コレクションが 1 ずつ増えるのはなぜですか?

増加するだけでなく、r.ConcreteType は例外を発生させません。これは、基になるオブジェクトが実際に存在することを意味します。ページは、それ自体が HttpContext スコープで宣言されているプレゼンターに挿入されます。

HttpContext スコープが正しく動作していないように見えるのは、何が間違っているのでしょうか?

前もって感謝します

いろいろ考えた結果、以下のようになりました。クラスの新しいインスタンスを作成するようにコンテナーを構成した場合(構成は Application_Start 中に 1 回だけ行われます)、コンテナーはインスタンスを作成し、Http 要求の最後で実際に削除します。ただし、このクラスの既存のインスタンスのみを登録します。コンテナーはインスタンスの所有者ではないため、コンテナーを削除することはできませんが、構成はコンテナーへの参照を保持します (したがって、コンテナーをまったく削除することはできません)。反対側では、構成アイテムはいつでも誰によっても削除されません (ただし、すべての Http 要求で追加されます)。

したがって、すべてが機能するように機能します。もちろん、それは「HttpContextScoped」（およびその他のいくつかのもの:-(）に対する私の誤解です。

だから、私は出発点にいます:そのような登録を構成から削除する方法はありますか?

【追記】このような登録は削除できないようです。解決策は、自動コンストラクター注入を手動プロパティ注入に置き換えることです。すなわち: プレゼンターを (そのビューなしで) 作成し、ビューを手動で設定します: thePresenter.View = this; 前述の登録は追加されず、問題は発生しません。

4

1 に答える 1

1

この行：

container.Configure(x => x.For<IMyInterface>().HttpContextScoped().Use(this));

誤解を招くです。として登録しているHttpContextScopedように見えますが、実際にはシングルトンとして登録されています。

ラムダを使用してオブジェクトを「作成」できます。

container.Configure(x => x.For<IMyInterface>().HttpContextScoped().Use(c => this));

オブジェクトの作成にはラムダ メソッドが使用されますが、通常のスコープ ルールは引き続き適用されます。実際、ファクトリを使用する場合は、スコープ ルールがまったく必要ない場合もあります (ラムダが遅延評価されるため)。

于 2012-08-11T01:03:33.603 に答える