Je sais qu'il y a beaucoup d'articles qui expliquent comment utiliser le CDI en Java EE, mais je vais avoir de la difficulté à décider quel avantage cela apporte réellement. Par exemple, supposons que j'ai une classe qui utilise une instance de Foo. Je peut faire
Foo myFoo = new Foo();
ou
// Better, FooFactory might return a mock object for testing
Foo myFoo = FooFactory.getFoo();
Je lis qu'avec le CDI je peux faire:
@Inject
Foo myFoo;
mais pourquoi est-ce mieux que le précédent usine approche? Je suppose que il y a un autre cas d'utilisation que je ne suis pas au courant, mais je n'ai pas été en mesure d'identifier cette.
Si j'ai bien compris les réponses ci-dessous, le concept est que le DI-cadre comporte comme un maître de la fabrique d'objet qui est configuré de manière centralisée. Est-ce une interprétation raisonnable?
Mise à jour
Depuis, j'ai commencé à apprendre le Printemps et maintenant cela fait beaucoup plus de sens. Le paragraphe ci-dessous est tiré de Printemps, dans la Pratique, en prenant un exemple d' AccountService de la classe qui, à son tour, utilise une instance de AccountDao. Je prie de m'excuser pour la longue citation, mais je pense qu'il est vraiment au cœur de pourquoi injecté des ressources, offrir quelque chose de plus standard à l'initialisation.
Vous pourriez avoir construit le AccountService à l'aide du mot clé new, mais la création d'un service objets de la couche est rarement aussi simples. Ils dépendent souvent de DAOs, mail de l'expéditeur, du SAVON procurations, et autres joyeusetés. Vous pourriez instancier chacune de ces dépendances par programmation dans le AccountService constructeur (ou par l'intermédiaire d'initialisation statique), mais qui entraîne dur dépendances et cascade de changements comme ils sont permutées.
En outre, vous pouvez créer des dépendances de l'extérieur et de les fixer sur le AccountService via des méthodes de définition ou des arguments du constructeur. Cela permettrait d'éliminer le dur interne dépendances (tant qu'elles ont été déclarées dans le AccountService par l'interface), mais vous auriez dupliqué code d'initialisation de partout. Voici comment créer un DAO et fils jusqu'à votre AccountService le Printemps façon:
<bean id="accountDao" class="com.springinpractice.ch01.dao.jdbc.JdbcAccountDao"/>
<bean id="accountService"
class="com.springinpractice.ch01.service.AccountService">
<property name="accountDao" ref="accountDao"/>
</bean>
Après avoir configuré les haricots comme ci-dessus, votre programme peut maintenant demander une instance d' AccountService depuis le Printemps ApplicationContext et le Printemps DI-cadre va s'occuper de instancié tout ce qui a besoin de l'instanciation.
