IoC Good practice

[dajtw]

Hi,

Can any experienced IoC/Spring developers give advice on when it would be ok to get the application context to get beans? I keep hearing it's ok if you're using it to 'glue' code together, what exactly do people mean by that? Everywhere I hear do not tie code down to Spring so does that mean in a well developed Spring application, there is absolutely no need for glue code?

Here's the situation I'm pondering upon... I have a class which is supposed to decide upon what type of report (bean) to instantiate(get) based on the results of processed data. How would I do this without using getBean()? Pass every single type of report (spring) bean into an object array of the class via Spring and then let the class decide which one to use via code ?

Would much appreciate some advice here as I'm just starting out on this IoC/Spring path; enjoying it but really would like to really nail down some basics..

[Colin Yates]

With regard to letting your classes "know" about Spring, that is really your call, but generally there is very little need for your classes to delve into Spring. The more you can let Spring do the wiring up for you the better

With regard to the class which needs a list of reports, it depends on *who* knows which report you need, does each report know whether it is suitable not. Either way, some kind of strategy is in order I think:

  interface ReportSelector {
    Report getReport(some.context...);
  }

This reportSelector would then be wired up with all the reports and then injected into your class via spring:

<bean class="yourClass" class="....">
  <constructor-arg>
    <bean class="your.ReportSelectorImpl">
      <property name="loggedInReport">
        <bean class="your.FirstReport"/>
      </property>
      <property name="loggedOutReport">
        <bean class="your.SecondReport"/>
      </property>
    </bean>
  </constructor-arg>
</bean>

and code:

  public class YourClass {
    private final ReportSelector reportSelector;
    public YourClass(final ReportSelector reportSelector) {
      this.reportSelector = reportSelector;
    }

    public void someMethod() {
      Report report = reportSelector.getReport(user etc.);
    }
  }

ReportSelector might look like:

  public class ReportSelectorImpl implements ReportSelector {
    private Report loggedInReport;
    private Report loggedOutReport;

    public Report getReport(final User user) {
      if (user.isLoggedIn()) {
        return loggedInReport;
      } else {
        return loggedOutReport;
      }      
    }

    public void setLoggedInReport(final Report report) {
      this.loggedInReport = report;
    }

    public void setLoggedOutReport(final Report report) {
      this.loggedOutReport = report;
    }

  }

The implementation of reportSelector is obviously silly but you get the idea

HTH.

[dajtw]

Thanks muchly for such a detailed response, sorry for the late response... it's always of great comfort to know how some new technology are handled by others more experienced to have a rough idea of how thing should be handled.

Based on your example, would that mean if I have like 400 plus reports, I'd have to wire them all into the one managing report management class? I am aware that we should try to steer clear of coding such that our code is locked into Spring and your method definitely does that. But how would you view simply using a getBean() on a bean that's simply named after the report? Or would a wired approach in the manner you suggest always be the much more preferred and cleaner route?

Much thanks for any input and comments in advance!!

[Injecteer]

well, I'd put all your 400++ reports into a Map (or some other indexed *maybe custom* storage). Then let the ResourceSelector pick the right one.

So, you code knows and cares only about it's internals. No information from the outside, as it would be a bean's name of the spring context, is involved, so there's no point to glue some external constraints.
Imagine, that you suddenly change your bean naming. In this case you would have to change your ReportSelector (400++ times!!).