I've seen two different strategies of injecting objects in Seam (in my case a DAO)
1.
@In(create="true")
private WeirdDao weirdDao;
...
@Name("weirdDao")
public class WeirdConcreteDao implements WeirdDao
2.
@In
private WeirdDao weirdDao;
...
@Name("weirdConcreteDao")
public class WeirdConcreteDao implements WeirdDao
...
components.xml
<factory auto-create="true" name="weirdDao" value="#{weirdConcreteDao}"/>
My theory is that in the second example Seam is taking care of the creation of the object and (hopefully) controls something like a pool of its instances.
Is there any oficial explanation of the pro/con of the usage of these two?
Thanks in advance!
The advantage in terms of performance is not that much concern in this case. But the problem is rather philosophical.
Factory Pattern is a well-known Creational design pattern. In Seam, we generally use factory method to created the instances of Entity or Domain type Classes. They generally holds data and does not has any processing or business logic.
For injecting the beans like Service or DAO, we generally don't use factory.
The main cause is, creation of Service or DAO type beans do not hold states or depend on any states. So why would I take the headache of writing factory method or configuration for that, where I can easily transfer the responsibility to the container.
But in case of Entity or Domain type beans may differ depending on states. For example, you need to create spouse bean depending on the user logged in. To do that you write a factory method to create spouse bean depending on the user. You generally do not depend on container to do that.
Hope this helps!