[
http://www.stripesframework.org/jira/browse/STS-520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11288#action_11288
]
Christian Nelson commented on STS-520:
--------------------------------------
No offense intended, but I disagree. And just for clarification, at no point
was I suggesting that there be a single Stripes-specific generic dependency
injection annotation which works across multiple DI frameworks.
Let's see if I can express why I think creating a unified Stripes-specific DI
annotation is a bad idea...
Unless Stripes is aiming to be an IoC container (very doubtful), I think it
should use the DI annotations and semantics of the DI frameworks providing IoC
functionality. Adding yet another way to mark something for dependency
injection just complicates the domain. Stripes is a great, lightweight MVC and
should keep its focus on doing just that. Let the DI frameworks define the
syntax and semantics since its their specialty.
Spring and Guice support are obviously very desirable and should be available.
What does support mean exactly? In my mind, Spring "support" means "support
integration between Stripes' actions and Spring managed beans (services) using
Spring's syntax and semantics", it does not mean "integrate with Spring managed
beans using a custom, non-Spring syntax." (Obviously the same sentence can be
modified for Guice support).
As a developer, having a generic annotation doesn't really make my life easier,
in fact it's adding some complexity in the form of another annotation for
dependency injection.
Having a single Stripes-specific annotation isn't going to make implementation
any easier. In fact, i think it will be more difficult because of the scenario
where multiple DI framework are in play. I know it's a bad idea, but it does
happen. For example, worked on a project where we were migrating from Guice to
Spring and for some time, both were active. Being explicit about where a
dependency comes from (Guice, Spring, etc) by using the native syntax of the DI
framework makes this easier to handle. Even ignoring this corner case
scenario, it's not going to be easier to implement a generic mechanism.
Lastly, using the generic annotation we lose the benefit of consistency
throughout an application, from the web tier back through the services.
In the end, I think we should support Guice and Spring both, but support them
using their native annotations.
> Support Spring's @Autowired annotation for marking fields/methods for
> dependency injection
> ------------------------------------------------------------------------------------------
>
> Key: STS-520
> URL: http://www.stripesframework.org/jira/browse/STS-520
> Project: Stripes
> Issue Type: Improvement
> Affects Versions: Release 1.4.3
> Reporter: Christian Nelson
> Priority: Trivial
>
> It'd be nice if we could use the @Autowired annotation that was recently
> added in Spring 2.5 in place of the @SpringBean annotation. Dependency
> injection would then would be consistent with a spring-managed service tier.
> Obviously this isn't a big deal and I've marked it as trivial.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://www.stripesframework.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
