开发者

Instantiation failure and singleton-behaviour interaction [NInject1]

开发者 https://www.devze.com 2022-12-25 07:18 出处:网络
I have set up a NInject (using version 1.5) binding like this: Bind<ISessionFactory>().ToMethod<ISessionFactory>(ctx =>

I have set up a NInject (using version 1.5) binding like this:

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>();

As you can see, this binding uses a singleton behavior but can also throw exception when something is not configured correctly, like a wrong connection string to the database.

Now, when the creation of a session factory fails at first (throwing a database exception), NInject doesn't try to create the object again but always returns null.

I would need NInject to check for null first and recreate when the instance is null, but of c开发者_开发技巧ourse not when there already is an instance successfully constructed (keeping it singleton). Like this:

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

Would I need to write a custom behavior or am I missing something else?


This doesnt make much sense.

Firstly, the point of a singleton is that everything depending on that item should see exactly the same thing - this is very hard to achieve if your factory method is going to change its mind.

Also, if you're talking about an NHibernate ISessionFactory (are you?), it's not going to have transient failures of this nature that can be recovered (or if it can, can you explain why - I'm no expert on it). I appreciate that the creation of a Session might fail (but you wouldnt be keeping it as a singleton), but that's a completely different to the creation of a factory failing (if you cant rely on your factories to have dumb constructors, what can you rely on?).

In terms of the NInject angle on this, the creation method (be it Factory or Provider) is separate to the scoping, so I doubt there's going to be a way to manage what you're looking to do cleanly (even if you can resolve the opening two questions). I highly recommend looking at the source - it's short and clean so if there's an answer, it'll jump right out at you. It'll take you no more than a minute to download - go do it!

Finally, a good article on managing NHibernate sessions (Which IIRC doesnt make any provision for session factory creation failure)

Now, to actually answer the question regardless of whether its a bad one - if it was possible for a failure to happen in the creation of the factory, and you couldnt adjust the factory in order not to do that (how many retry looks have you seen for creating factories?), the answer is that you'd move the retry logic (for creating the Factory) into a Provider or Method that's responsible for creating Sessions, which can then retry in a manner that you see fit.

0

精彩评论

暂无评论...
验证码 换一张
取 消