J'ai une application qui a plusieurs écrans et chaque écran est sélectionné via un bouton. Chaque écran contient des composants assez poids lourds, il est donc important que seul l'écran d'activation soit en mémoire - tous les autres devraient être disponibles pour la collecte des ordures.
L'application utilise le ressort pour la colle et il commute actuellement des écrans à l'aide de GetBean (): < / p> "écran1" est un haricot prototype de sorte qu'une nouvelle instance de l'écran est créée lorsque vous appuyez sur le bouton. En outre, SetScreen () est le seul endroit où une référence à l'écran est maintenue dans l'application afin que l'écran précédemment actif soit disponible pour la collecte des ordures. Je n'ai pas encore testé cela mais je m'attends à ce que cela fonctionnerait bien - pas de science de fusée ici! Le problème est - après la lecture Cette page sur pourquoi getbean () est considérée comme mauvaise - je me demande s'il y a un moyen plus idiomatique de réaliser les mêmes résultats tout en supprimant la dépendance tout en supprimant la dépendance À GetBean (). J'ai examiné l'injection de la méthode et que cela me ressemble d'introduire une complexité avec peu d'avantages. C'est un autre concept d'apprendre, plus de magie, ajoute une dépendance sur cglib, etc. Si je veux vraiment supprimer la dépendance au printemps, je peux simplement introduire une interface qui expose la méthode getbean (). getbean () et la méthode injection des seules options dans mon cas ou ai-je manqué quelque chose? et si oui, est getbean () vraiment si mauvais?
3 Réponses :
Avez-vous envisagé une approche d'usine?
<bean id="screenFactory" class="com.myclass.ScreenFactory"/> <bean id="myapp" class="..."> <property name="screen1" ref="screenFactory"/> </bean>
Donc, dans votre solution, getbean () est invoqué dans la méthode de création d'usine (), non?
Pas exactement. Il est remplacé par une méthode d'usine, mais il est beaucoup plus facile de se moquer de l'interface ci-dessus que de se moquer d'un contexte d'application. De plus, il est pluggable. En fin de compte, il s'agit d'une mise en œuvre un peu plus simple de l'injection de méthode du printemps static.springsource.org/spring/docs/2.5.x/reference/...
Je vois, mais d'où crée l'usine () méthode obtient son instance d'écran?
Injection de réglage, injection de propriété ou injection de constructeur Tout créez une application couplée de manière lâche qui est beaucoup plus facile à tester par la moqueur. Il empêche également l'une de vos classes d'avoir des dépendances directes sur les classes de printemps (ou d'autres conteneurs IOC). Il finit comme étant une solution globale plus propre lorsque vous n'avez pas à appeler manuellement getbean ().
Je pense que vous devriez devenir à l'aise avec la notion de configuration de dépendances. La "magie" n'est pas vraiment magique du tout et est juste quelque chose que vous allez être à l'aise avec comme vous l'utilisez.
Je parle d'injection de méthode à l'aide de la balise de méthode de recherche que IMO est différente de «standard» injection de dépendance - c'est une fonctionnalité distincte et une fonctionnalité qui repose sur un AOP (et donc cglib) et que cela vous donne-t-il sur une usine (quel clôt a démontré?)
L'usine isolera votre dépendance au printemps, mais cela devient ce que je pense, c'est juste un code inutile à maintenir. Quel est le problème avec un AOP? AOP est juste un détail de mise en œuvre de la façon dont le printemps fait di.
Si vous voulez simplement vous débarrasser de la getBean, envisagez d'utiliser un ServiceLocatorFactoryBean . Mais dans quelle mesure cela fonctionne-t-il peut-être peut-être sur l'endroit où la chaîne "Screen1" vient de votre application.