-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[DI][Proposal] Annotation-based autowiring #25810
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'm -1 for providing direct autowiring into private properties. This would mean that your class is unusable in a normal way. and btw, injecting a service into a Doctrine entity is a bad signal about the architecture... |
@stof - sorry, my bad, I meant "inject the same way as doctrine does". Entities are unrelated here, sorry for the confusion. Class with 3-4 constructor arguments is also unusable in "normal way". See http://www.baeldung.com/spring-autowire . Description updated. |
@andrewtch it is not unusable. It is unfriendly. this is not the same. Forcing to use reflection to use a class means that your class is restricted to be used by systems bypassing the API of your class (btw, it also means that such class is almost untestable as you would not use the DIC to initialize it in tests...). And btw, this cause another sort of issue: PHP properties cannot be typed, so there is no reliable way to know the type for autowiring (the phpdoc is hard to use, because we would have to resolve class names in them manually, forcing to parse the source code ourselves to know use statements, etc... Phpdocumentor has a whole library dedicated to parsing phpdoc, with lots of the logic related to this resolution of FQCN and terrible performance) |
Good point. I will dig in more on Spring's approach to autowiring and tests. PHPDocumentor parsing is indeed slow, noticed it on Swagger documentation. |
When we designed the 2.8 version of the autowiring mechanism, we tried hard to avoid such solution because of the arguments mentioned by @stof, and because the classes should know nothing about the DIC (and basically the way they are initialized). The only exception (and I'm not fond of it is I'm 👎 to add this too. It will be slower and encourage bad design. |
Regarding properties's types and PHPDoc parsing, we can use the PropertyInfo component for that (it has a cache layer for performance). But as said previously I wouldn't go this way. |
👎 as well, closing. |
Anyway, it can be done as a community bundle. |
I propose to introduce
@Autowire
annotation that will inject services into private / protected properties (the same way as Doctrine does with entities) instead of passing them to constructor. This can work like so:This would mimic Spring's
@Autowired
annotation and allow simpler DI if necessary, especially when inheriting services (on a small performance cost of reflection call, which is to be measured). Of course, container - injection should stay.Was this behaviour discussed before?
See: http://www.baeldung.com/spring-autowire
The text was updated successfully, but these errors were encountered: