In my opinion POJOs with dependencies specified in constructor only is far more understandable than service locator. What is understandable is simple and stable. Stability and predictability of simple things is my choice. Thats why I think that dependency on a locator _is_ a problem.Alexander Zhukov wrote:
By mentioning JNDI I guess you are talking about ServiceLocator pattern, right? It is considered as anti-pattern.
Not here:
http://jroller.com/comments/kdonald?anchor=static_service_locator_with_spring
nor here:
http://www.martinfowler.com/articles/injection.html#ServiceLocatorVsDependencyInjection
"the decision between locator and injector depends on whether [the dependency on a locator] is a problem."
HOWEVER, as a migration step from service locator to full cdi style solution, the explicit statement of a dependency on a locator in a CDI POJO would be acceptable.
You might ask: "what do you mean, man?" :)
Example:
BAD:
class MyComponent ... {
init() {
context = InitialContext();
Service s = context.lookup(...);
} run() {
s.doSomething();
}
}GOOD: (acceptable but not an excelent design solution)
class MyComponent {
public MyComponent(Context ctx, ...) {
Service s = ctx.lookup()
} run() {
s.doSomething();
}
}
nor here ...
http://corej2eepatterns.com/Patterns2ndEd/ServiceLocator.htm http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html http://java.sun.com/blueprints/patterns/ServiceLocator.html http://www.oracle.com/technology/sample_code/tech/java/j2ee/designpattern/businesstier/index.html http://www.instantiations.com/codepro/ws/docs/features/patterns/service_locator_pattern.html
--- Noel
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
