Description:
The idea of having 'scopes' for services comes from the fact that this library was inspired by ASP Core's Dependency Injection,
which provides similar functionality.
In ASP Core there is a need for each HTTP request to have its own 'ecosystem' for services (its own 'scope').
For example, you don't want your database context to be shared between different requests at the same time, as each request needs
to make/discard their own chnages to the database. Having a seperate database context between each request (scope) allows this to be
achieved easily.
For a lot of programs, you probably won't need to use scopes at all, and can simply use ServiceProvider.defaultScope for all of your
needs. Use what's best for your case.
Master & Slave ServiceScope:
There are two variants of ServiceScope that can be accessed - master scopes, and slave scopes.
The principal is pretty simple: Master scopes are the 'true' accessor to the scope so therefore contain the ability to also destroy the scope.
Slave scopes, however, can be seen more as a 'reference' accessor to the scope, meaning that they cannot destroy the underlying scope in anyway.
Destroying a scope:
There are two ways for a service scope to be destroyed.
1. The master ServiceScope object has its dtor run. Because the ServiceScope is the master accessor, then the scope's lifetime is directly tied to the ServiceScope's lifetime.
2. A call to ServiceProvider.destroyScope is made, where a master ServiceScope is passed to it.
The ServiceScope object is non-copyable, so can only be moved via functions like std.algorithm.mutation.move
Currently when a scope it destroyed nothing really happens except that the ServiceProvider clears its cache of service instances for that specific scope, and allows
another scope to be created in its place.
In the future I will be adding more functionality onto when a scope is destroyed, as the current behaviour is a bit undesirable for multiple reasons (e.g.
if you destroy a scope, any uses of a ServiceScopeAccessor for the destroyed scope can trigger a bug-check assert).
Provides access to a service scope.
Description: The idea of having 'scopes' for services comes from the fact that this library was inspired by ASP Core's Dependency Injection, which provides similar functionality.
In ASP Core there is a need for each HTTP request to have its own 'ecosystem' for services (its own 'scope').
For example, you don't want your database context to be shared between different requests at the same time, as each request needs to make/discard their own chnages to the database. Having a seperate database context between each request (scope) allows this to be achieved easily.
For a lot of programs, you probably won't need to use scopes at all, and can simply use ServiceProvider.defaultScope for all of your needs. Use what's best for your case.
See https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection as the documentation there is mostly appropriate for this library as well.
Master & Slave ServiceScope: There are two variants of ServiceScope that can be accessed - master scopes, and slave scopes.
The principal is pretty simple: Master scopes are the 'true' accessor to the scope so therefore contain the ability to also destroy the scope.
Slave scopes, however, can be seen more as a 'reference' accessor to the scope, meaning that they cannot destroy the underlying scope in anyway.
Destroying a scope: There are two ways for a service scope to be destroyed.
1. The master ServiceScope object has its dtor run. Because the ServiceScope is the master accessor, then the scope's lifetime is directly tied to the ServiceScope's lifetime.
2. A call to ServiceProvider.destroyScope is made, where a master ServiceScope is passed to it.
The ServiceScope object is non-copyable, so can only be moved via functions like std.algorithm.mutation.move
Currently when a scope it destroyed nothing really happens except that the ServiceProvider clears its cache of service instances for that specific scope, and allows another scope to be created in its place.
In the future I will be adding more functionality onto when a scope is destroyed, as the current behaviour is a bit undesirable for multiple reasons (e.g. if you destroy a scope, any uses of a ServiceScopeAccessor for the destroyed scope can trigger a bug-check assert).