Nous devons fondamentalement pouvoir ajuster le comportement au moment du démarrage, en fournissant des classes souhaitées à produire par diverses usines à l'intérieur de notre application (pour éviter la liaison difficile du "nouveau" opérateur).
Je suis conscient que cela est fourni par plusieurs grands cadres, mais je cherchais quelque chose facilement utilisé par une application Java autonome sans être gigantesque.
Toute suggestion?
Edit: C'est mon expérience que ces cadres ont tendance à grandir dans le cadre de la maturation (et du complexe aussi). J'ai besoin que cela soit réalisable à une application héritée dans le cadre du refactoring majeur (dette technique), la simplicité est donc essentielle des bibliothèques usagées. Cela ne me dérange pas de devoir faire un peu de codage dans notre application, mais il doit être très visible ce qui se passe. AOP a tendance à déménager des choses, et cela peut rendre l'application plus difficile à maintenir.
Edit: Nous avons maintenant atteint le point où nous devons réellement prendre une décision. La demande vivra probablement pendant des décennies afin que nous devons prendre une décision réversible avec un cadre qui sera maintenu pour espérer aussi longtemps. J'aime beaucoup la vérification de type statique disponible avec Guice, mais pas que les annotations se lient explicitement à Guice au lieu d'être externes comme au printemps. J'aime aussi que ce code semble être plus concis lors de l'utilisation de Guice par opposition au printemps. Nous avons besoin de quelque chose qui est robuste et utile. Nous n'avons pas besoin de plus que juste di pour le moment. Existe-t-il un cas d'utilisation que définitif dit aller pour l'un d'entre eux?
EDIT 2011-07-27: La décision finale consistait à utiliser l'API JSR-330 dans le code et choisir un par projet si pour utiliser le ressort, la bande ou la soudure. Pour les applications autonomes, Guice a bien fonctionné jusqu'à la mise en œuvre de la JSR-330.
10 Réponses :
Avez-vous regardé le Google Guice cadre? C'est assez léger et basé sur l'annotation, en évitant les fichiers de configuration Il y a aussi pico - et nano-conteneur (de codehaus) qui sont assez légers bien que la dernière fois que j'ai regardé (certes il y a quelques années), la documentation manquait.
Je dois dire que je suis d'accord avec les autres sur ce que je suppose, c'est votre présomption que le printemps est massif et déroutant. C'est vraiment un conteneur de COI très simple et d'être recommandé. xml
J'utilise le printemps pour câbler mes applications client.
Nous avons décidé pour Guice pour l'instant, puis migrer vers JSR-330 lorsqu'il y a plus d'une implémentation.
Il y a un couple que je sais que vous pourriez trouver utile:
J'ai trouvé le plexus très utile dans les applications autonomes car il comporte des composants utilitaires facultatifs pour l'interaction CLI.
Vous pouvez toujours utiliser le cadre de printemps 2.5. C'est un gros, mais si vous prévoyez d'utiliser uniquement DI, vous pouvez utiliser des modules à ressort et de haricots à ressort, qui sont assez petits (environ 500kb et 300kb).
Il y a aussi Google Guice 2.0 qui est livré avec un paquet avec seulement des éléments de base (pas de AOP) et il est de 430 Ko.
Je pense que vous avez également besoin de contexte de printemps. Et la journalisation des communes?
Par "gigantesque" Je vais supposer que vous parlez de printemps, mais c'est injuste, puisque vous pouvez chercher des morceaux de printemps que vous souhaitez utiliser. Si tout ce dont vous avez besoin est le conteneur IOC, utilisez simplement les fichiers JAR appropriés et le bit approprié de l'API, et ignorez le reste de celui-ci.
Ces «cerises» peuvent bien être des cerises assez lourdes. Une application printanière de 664K s'est avérée devenir une application de 1,9 m en basant simplement au printemps. Le noyau de printemps, les haricots et le contexte s'élèvent à 1,2 m. Que fondamentalement aussi petit que possible.
La plupart des réponses semblent donc être préoccupées par la taille des fichiers JAR à ajouter.
Cependant, je pense que la question la plus importante est l'impact sur le projet: combien de lignes Même le «gros» cadre de printemps est en fait très facile à utiliser:
Vous avez essentiellement besoin de:
La bonne chose est que le printemps est au mieux l'endroit unique où vous initialisez réellement le conteneur à ressort est le seulement
Place dans votre application qui a une dépendance réelle pour les classes de printemps.
Quel est le problème avec printemps ?
Ces jours-ci, il est assez bien emballé pour que vous n'ayez pas besoin de prendre l'ensemble du kit et du Caboodle.
En tant que mis à part, je ne suis pas un fan des cadres d'injection basés sur l'annotation. En effet, les annotations sont liées à la classe plutôt que l'instance, plus une pré-requise, IMHO, pour DI. Cela signifie que chaque instance d'une classe donnée reçoit le même objet injecté, ce qui semble vaincre le point.
considère également que DI n'a même pas besoin d'un cadre, quel est le problème avec votre méthode principale câblant ensemble l'application?
Si vous n'êtes pas un fan d'injection à base d'annotation, alors le Spring Me est génial. (Cela ne le supporte pas. ;-) Cela pourrait cependant, mais ça ne le veut pas.)
Si vous voulez quelque chose de simple simple et approprié, écrivez alors du code qui fait ce que vous voulez faire. Vraisemblablement, cela implique un câblage ensemble des usines basées en partie sur une logique fixe, et en partie sur les paramètres d'exécution.
Ceci présente l'avantage que l'ensemble des configurations de temps d'exécution possibles est connue et tellement documentable et testable.
Il a l'inconvénération qu'un déploiement d'un changement logique imprévu prend intrinsèquement une seconde supplémentaire d'une seconde de compilation, et (plus de manière significative) ne peut être introduit dans la production sans tester pleinement en le dissimulant comme "juste un changement de configuration" .
Je suggère fortement de jeter un coup d'œil à printemps-moi . Bien que l'on entendait à l'origine être un moyen d'utiliser le printemps sur les applications Java Me, cela fonctionne également bien pour les applications autonomes.
vrai, cela ne vous donne pas toutes les cloches et sifflets que le printemps (plein) a à offrir, mais encore une fois, le printemps complet est beaucoup plus qu'un cadre d'injection de dépendance simple.
sur le côté plus: il est basé sur un sous-ensemble (conforme) des fichiers de configuration du ressort et l'empreinte de l'heure d'exécution est de 0%. En fait, il n'y en a pas. Spring Me prendra votre contexte de candidature et la transformera en une classe qui n'a aucune dépendance sur les classes autres que les vôtres.
Il y a environ un an, je me suis posé une question très comme celle-ci. Donc, je passe quelques heures à lire la documentation du printemps et de la Guice. Après environ une heure avec le printemps, j'ai été laissé sentir que je pouvais obtenir une application Web de base, mais je n'avais aucune idée de la manière de l'utiliser dans une application autonome. Après une heure avec le document de Guice, tout avait cliqué et je pouvais voir juste comment je voudrais faire ce que je voulais faire. Maintenant, pour recommander Guice? Et bien non. Qu'est-ce que votre équipe sache déjà? Si quelqu'un sait déjà dire le saut de printemps que la connaissance et les faire répandre. Comme sage avec Guice ou Pico.
Nous deux d'entre nous sont assez vides pour le moment, d'où la question sur les expériences: D
Si vous voulez quelque chose de très léger, vous voudrez peut-être jeter un coup d'œil sur Fuse c'est équitablement extensible alors pourrait être ce que vous recherchez.
acclamations
n