1

私は次のようにNInject（バージョン1.5を使用）バインディングを設定しました：

Bind<ISessionFactory>().ToMethod<ISessionFactory>(ctx => 
{
    try
    {
        // create session factory, might fail because of database issues like wrong connection string
    }
    catch (Exception e)
    {
        throw new DatabaseException(e);
    }
}).Using<SingletonBehavior>();

ご覧のとおり、このバインディングはシングルトン動作を使用しますが、データベースへの接続文字列が間違っているなど、何かが正しく構成されていない場合にも例外をスローする可能性があります。

これで、セッションファクトリの作成が最初に失敗した場合（データベース例外がスローされた場合）、NInjectはオブジェクトの再作成を試みませんが、常にnullを返します。

最初にnullをチェックし、インスタンスがnullのときに再作成するには、NInjectが必要ですが、もちろん、インスタンスが正常に構築されている（シングルトンを維持している）場合は必要ありません。このような：

var a = Kernel.Get<ISessionFactory>(); // might fail, a = null
// ... change some database settings
var b = Kernel.Get<ISessionFactory>(); // might not fail anymore, b = ISessionFactory object

カスタム動作を作成する必要がありますか、それとも何か他のものが欠けていますか？

4

1 に答える 1

1

これはあまり意味がありません。

まず、シングルトンのポイントは、そのアイテムに依存するすべてがまったく同じものを参照する必要があるということです。これは、ファクトリ メソッドの気が変わった場合に達成するのが非常に困難です。

また、NHibernate について話している場合ISessionFactory(そうですか?)、回復可能なこの性質の一時的な障害は発生しません (または、回復できる場合は、その理由を説明できます - 私はその専門家ではありません)。Session の作成が失敗する可能性があることは承知していますが (ただし、それをシングルトンとして保持することはできません)、それはファクトリの作成が失敗することとはまったく異なります (ファクトリがダム コンストラクタを持つことに依存できない場合、何ができるでしょうか)。に頼る？）。

これに関する NInject の角度に関しては、作成方法 (Factory であれ Provider であれ) はスコーピングとは別のものであるため、あなたがやろうとしていることをきれいに管理する方法があるとは思えません (たとえ解決できたとしても)。最初の 2 つの質問）。ソースを見ることを強くお勧めします。短くてきれいなので、答えがあればすぐに飛び出します。ダウンロードには 1 分もかかりません。

最後に、NHibernate セッションの管理に関する優れた記事(IIRC は、セッション ファクトリの作成の失敗については何も規定していません)

さて、それが悪いものであるかどうかに関係なく、実際に質問に答えるために-ファクトリの作成に失敗する可能性があり、それを回避するためにファクトリを調整できなかった場合（何回再試行したように見えるか）ファクトリの作成に見られますか?)、答えは、(ファクトリを作成するための) 再試行ロジックを、セッションの作成を担当するプロバイダまたはメソッドに移動し、適切と思われる方法で再試行できるようにすることです。

于 2010-04-06T08:25:41.480 に答える