Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>By default, Ninject will choose the constructor that has the largest number of parameters, which it has enough binding information to fill. So if the Ninject module is capable of providing an ISystemClock implementation, Ninject will prefer the second constructor.</p> <p>The pattern you're showing here is often used when you want to allow for injected dependencies, but still have a logical default to fall back on in the absence of a specific dependency. As you pointed out, you can provide your own ISystemClock mock when unit testing, which gives you the advantage of deterministic testing. Likewise, if you had some reason to want to provide a custom ISystemClock implementation, you could set up your Ninject modules with a matching binding.</p> <p>On the other hand, for most purposes the stock SystemClock implementation is probably the best one to use, so rather than forcing you to set up an ISystemClock binding in order for the class to even function, an alternate constructor is provided which uses the SystemClock as a default implementation. Ninject will fall back on this constructor if you haven't specified a binding for the ISystemClock service.</p> <p><strong>Edit</strong></p> <p>In this particular case, the reason it's not running is due to the following attribute on the TimeService class:</p> <pre><code>[ServiceBehavior( InstanceContextMode = InstanceContextMode.Single )] </code></pre> <p>I don't fully understand what all is going on here, but it is somehow preventing Ninject from being used to create the service. If you comment out this line, it should work as expected.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload