I got the IUnitOfWork interface (with its implementation which I wont show you):
public interface IUnitOfWork : IDisposable
{
...
}
Note the IDisposable inheritance. Also, I got the service with the appropriate implementation:
public interface IBusinessLogicService
{
...
}
public sealed class BusinessLogicService : IBusinessLogicService
{
// Dependency is auto-injected by ninject
// because of the custom injection heuristic.
public IUnitOfWork UnitOfWork { get; set; }
...
}
There we go the ninject binding:
kernel.Bind<IUnitOfWork>().To<UnitOfWork>().InRequestScope();
kernel.Bind<IBusinessLogicService>().To<BusinessLogicService>();
As you can see, ninject will automatically deactivate the IUnitOfWork instance at the end of the request and also dispose it.
Now, the question,
will the ninject also deactivate (and reactivate on the next web request) the instances (like IBusinessLogicService) that are dependent on the deactivating object?
No, Ninject will deactivate an object when the scope is collected if there is a scope. Transient objects are not tracked by Ninject and are considered to be managed externally [and fresh instances are created wherever one is required].
The deactivation point for a scope worth of objects is normally dictated by when the scoping object gets garbage collected.
For
InRequestScopethe deactivation takes place deterministically at the end of a request using an ASP.NET pipeline hook.See also
Ninject.Extensions.NamedScopefor more options in this space