Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>Does it makes sense in Spring to use <code>@Autowired</code> to wire directly to a concrete class and not to an interface</p> </blockquote> <p>Sure. The practice of autowiring is independent of <em>what</em> you're autowiring. It'll work with classes just as well as interfaces.</p> <p>However, whether or not it's a good idea is debatable, although this is a more general question of whether you should always introduce an interface for a given class, rather than talk directly to the class type. The benefits include easier unit-testing and a cleaner design, at the expense of code clutter. </p> <p>There's another good reason to autowire interface types rather than class types, which is that if Spring needs to generate a proxy object around the bean before injecting it, then if the bean's class defines <em>any</em> interfaces, then the proxy will implement those interfaces, and will <em>not</em> be type-compatible with the bean class itself. If you then try and autowire that bean by class type, it will fail. The easiest way to avoid this annoying scenario is to always autowire by interface type, that way it will lways work as you expect.</p> <blockquote> <p>and make use of 'by type' autowiring</p> </blockquote> <p>If you mean <a href="http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-factory-autowire">container-level <code>byType</code> autowiring</a>, then you don't want to do that. It's the old Spring 1.x style of autowiring, and it's highly inflexibile (see <a href="http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-autowired-exceptions">limitations of autowiring</a>).</p> <p>Stick with <code>@Autowired</code>, it's much more flexible and easier to control.</p> <blockquote> <p>If a class doesn't implements an interface wouldn't it be better to instantiate it via constructor or a factory (keeping things simple); rather than make it a Spring bean just for the heck of it.</p> </blockquote> <p>The two questions are completely separate. An object should be made a Spring bean if you need Spring to control its dependencies and lifecycle, regardless of whether or not it implements interfaces. If you find that the object has no dependencies, and no meaningful interface, then perhaps there is no reason to make it a bean. </p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload