As you can see, the BookwormOracle class not only implements the Oracle interface but also defines
the setter for Dependency Injection. Spring is more than comfortable dealing with a structure like this--
there is absolutely no need to define the dependencies on the business interface. The ability to use
interfaces to define dependencies is an often-touted benefit of Setter Injection, but in actuality, you
should strive to keep setters used solely for injection out of your business and DAO interfaces. Unless
you are absolutely sure that all implementations of a particular business interface require a particular
dependency, let each implementation class define its own dependencies and keep the business interface
for business methods.
Although you shouldn't always place setters for dependencies in a business interface, placing setters
and getters for configuration parameters in the business interface is a good idea and makes Setter
Injection a valuable tool. We consider configuration parameters to be a special case for dependencies.
Certainly your components depend on the configuration data, but configuration data is significantly
different from the types of dependency you have seen so far. We will discuss the differences shortly, but
for now, consider the business interface shown in Listing 4-9.
Listing 4-9. The NewsletterSender Interface
package com.apress.prospring3.ch4;
public interface NewsletterSender {
public void setSmtpServer(String smtpServer);
public String getSmtpServer();
public void setFromAddress(String fromAddress);
public String getFromAddress();
public void send();
}
The NewsletterSender interface is implemented by classes that send a set of newsletters via e-mail.
The send() method is the only business method, but notice that we have defined two JavaBean
properties on the interface. Why are we doing this when we just said that you shouldn't define
dependencies in the business interface? The reason is that these values, the SMTP server address and the
address the e-mails are sent from, are not dependencies in the practical sense; rather, they are
configuration details that affect how all implementations of the NewsletterSender interface function.
Spring's Dependency Injection capabilities form the ideal solution to the external configuration of
application components, not for dependency provision but as a mechanism for externalizing
component configuration settings. The question here then is this: what is the difference between a
configuration parameter and any other kind of dependency? In most cases, you can clearly see whether a
dependency should be classed as a configuration parameter, but if you are not sure, look for the
following three characteristics that point to a configuration parameter:
Configuration parameters are passive. In the NewsletterSender example shown in
·
Listing 4-8, the SMTP server parameter is an example of a passive dependency.
Passive dependencies are not used directly to perform an action; instead, they are
used internally or by another dependency to perform their actions. In the
MessageRenderer example from Chapter 2, the MessageProvider dependency was
not passive--it performed a function that was necessary for the MessageRenderer
to complete its task.
Configuration parameters are usually information, not other components. By this
·
we mean that a configuration parameter is usually some piece of information that
a component needs to complete its work. Clearly, the SMTP server is a piece of
Search WWH :
