Spending some time sifting through documentation, I'm trying to figure out the best software architecture with or without the dispose pattern.
I've built the Repository pattern many time over the years, whilst using the dispose pattern which conformed to "best-practise". I actively use Ninject in which has configuration as follows:
/// <summary>
/// Starts the application
/// </summary>
public static void Start()
{
DynamicModuleUtility.RegisterModule(typeof(OnePerRequestHttpModule));
DynamicModuleUtility.RegisterModule(typeof(NinjectHttpModule));
bootstrapper.Initialize(CreateKernel);
}
/// <summary>
/// Load your modules or register your services here!
/// </summary>
/// <param name="kernel">The kernel.</param>
private static void RegisterServices(IKernel kernel)
{
Bind<DBContext>().ToSelf().InRequestScope();
}
As you can see, we have "OnePerRequestHttpModule" and "InRequestScope" for the DB Context, on the assumption that the "caller" of an object that implements the IDisposable is responsible for the disposing of that object.
Do I ever need to dispose of an object if it's Ninjects responsibility?
I have multiple naïve repositories that injects the context at runtime, with one per http request and the context of "in request scope" thus the context being passed around in the life time of a request.
The joy's of finding deeper understanding.
