Service registration

[ZFi88]

Hello! What do you think about using some custom attributes for marking classes, which needs to be registred in container, maybe [Service]? Also we can using attributes for marking classes life time scope([Transient], [Scoped], [Singleton])). By that change we can register dependencies in one call... I can create pull request for you.

[JonPSmith]

Hi @ZFi88,

There are some good ideas in there, and thanks for asking before you did a pull request. Many people just do a pull and I have to sort it out afterwards, which is a pain

I like what you propose, but suggestion the following changes:

1. [Service] isn't a good idea as its a breaking change, i.e. I would have to add [Service] on all of my services! How about the opposite [DoNotAutoRegister]. I would find that useful.
2. I like your idea of scope [Transient], [Scoped], [Singleton] attributes, but I worry about name clashes and intellisence. How about [RegisterAsTransient], [RegisterAsScoped], [RegisterAsSingleton]

Please add unit tests and comments on your attributes. I will check it out and release it and update the documentation. I am busy so there may be a delay.

[ZFi88]

About your changes:

1. Can we stay on current implementation and add additional method for scan services by attribute [Service]? So that will not breaking anything for current projects, and for new projects it will be very comfortably.
2. Yes your variant is better.

[JonPSmith]

On item 1, my experience of using AutoRegisterDi is that you want it to register everything, but there may be one or two you don't want to register. Therefore a [DoNotAutoRegister] is much more useful than a [Service] attribute.

AutoRegisterDi is about simple registering with DI so the attributes should be for the unusual situations, not the normal situations.

[ZFi88]

ok, i will try create merge request in the coming days