Skip to content

Conversation

@dominikschlosser
Copy link

Hi,

i have added attributes for the three default scopes (Singleton, Thread, Transient) and extended the configuration builder to auto-configure scopes by using these attributes.
This change is inspired by Java EE's Contexts and Dependency Injection (CDI) specification, where you are able to define contexts (scopes) via annotations.

Custom scopes can easily be added by creating a new attribute which inherits from "ScopeAttribute" and implements its abstract method "Configure".

@scott-xu
Copy link
Member

But this makes the service to depend on Ninject.Extensions.Conventions

@dominikschlosser
Copy link
Author

Yes, you are right but it is just another option, you are not forced to use it.
It is the price for a lot less configuration if you are using scopes heavily.

Coming from a java background, i really fell in love with the ease of use of CDI.
Most of the time you dont need any configuration, neither xml nor code-based. Thats possible by heavy use of annotations and good conventions.
These changes enable a very CDI-like usage of Ninject but are not enforcing it.

To avoid dependencies on Ninject.Extensions.Conventions the added scope-attributes could be moved to a separate "interface"-project or, if you really want the possibility to not have any ninject-dependency in a loaded assembly, i could add a mechanism, where all attributes with the name "xyScoped" would be evaluated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants