Eeek, I didn't mean to start an argument about DI ;)
It sounded a "little" like it ;)
I gots to work on those communication skills then ;)
I like that they're public so that people CAN see what dependencies
they have. It's really IMO a question of reuse to me. If you don't
want reuse encapsulate all you can (e.g. ServiceLocator), but if
you want reuse make it clear what dependencies your class has so
the others can see it. I really hate when I need to reuse code from
other projects and suddenly I'm faced with a ton of dependencies
that I first of all can't see exists and often ServiceLocators that
I suddenly have to understand (how are do I tell them where they
what implementations to use, property files, xml files, java code).
If each project have their own way of doing ServiceLocators it
hurts reuse.
Note: When I talk about doing dependency injection and showing
dependencies then I'm only focusing on course grained objects
(services, DAOs, resources, strategies, infrastructural objects,
etc.). Some dependencies are best encapsulated.
That's cool. And I think this it *the* primary use/benefit of DI.
When you expect to use the same components across projects then DI is
the best way to assemble them because the assembly can be
orchestrated externally.
All the new stuff is additional. If you want to continue to use
the setter, you will need to annotate the setter though.
Okay, so they injection will happen on the field directly if it's
annotated (as you can understand by my question then I haven't had
time to try it yet)?
Yup. Without realizing it, it works a lot like hibernate
annotations. If you annotate the field you get field access and if
you annotate the method you get property access.
-t
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
