0

I understand that if you directly new up an object that Spring has now way to inject a dependency specified by @Autowired.

However, say you have a UI in which create new Customer objects. I believe that newing up a Customer prior to persisting it is the only way to go. If that is so, what if I want Customer to have some complex behavior that requires access to some service that would normally be autowired?

Is it possible that once the Customer object is saved and then retrieved at that point Spring will be able to inject the autowired dependencies? So that the mistake is trying to use the Customer object "too early?"

My main question is, Is wanting to use Autowired in a newed up object reflective of a design flaw?

EDIT: I have seen ways that a newed up object can in fact use Autowire but again my question is, for common classes like Customer, User, Person, etc. is it unusual for them to even need to use @Autowired? Should they essentially be data-only objects? I seem to have need to both create new objects and have those objects exhibit behavior but maybe I am doing something wrong design-wise.

Jeff
  • 1,513
  • 4
  • 18
  • 34
  • 1
    Your shouldn't have any fields that required to be autowired in entity. It's should be just a POJO. If you have autowired fields in your entities (Customer, User) it's a incorrect architecture – Sergii Getman Oct 12 '16 at 11:41
  • Why should it always be a POJO? What if it wants to access a service? – Jeff Oct 12 '16 at 11:43
  • 2
    Because it is just an object that represent a data (entity from DB, DTO), no other sense in entity, common Spring Boot architecture is: Controller -> Service -> Repository -> Entity (POJO). So have service in entity is incorrect – Sergii Getman Oct 12 '16 at 11:47
  • 1
    I cannot think of any logical use-cases of such design but if you still want to implement it then take a look at the accepted answer on http://stackoverflow.com/questions/28365154/autowired-not-working-in-a-class-entity – madteapot Oct 12 '16 at 11:50
  • I think you are right. – Jeff Oct 12 '16 at 13:14

2 Answers2

1

You may create multiple instances of an object on the fly with an org.springframework.beans.factory.ObjectFactory<T> in Spring, which is like the javax.enterprise.inject.Instance<T> interface of Java EE CDI. See: http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/beans/factory/ObjectFactory.html

@Autowired
ObjectFactory<Customer> customerFactory; 

...
Customer newCustomer = customerFactory.get();
...

If the "Customer" is your entity class, you should avoid autowiring services.

How does your implementation look like? Could you provide more details?

Marcel Effinger
  • 86
  • 3
  • I am thinking my fundamental design might be wrong as Sergii suggests. The objects that I am newing up should probably not call services directly but rather be passed to services. – Jeff Oct 12 '16 at 13:14
0

I believe that Sergii's confirmation that the design is flawed is correct and I communicated with the app's original designer. So even if one could jump through hoops to autowire newed-up objects, it is not consistent with the original design or apparently Spring Boot's approach according to Sergii.

I see a way of doing what I need without autowiring -- the newed-up objects' complex behavior is now done elsewhere in the application.

Jeff
  • 1,513
  • 4
  • 18
  • 34