Le cadre de printemps est non intrusif.
Pouvez-vous s'il vous plaît élaborer cela?
Merci:)
4 Réponses :
Ici, "non intrusif" signifie que votre code d'application n'a pas besoin de dépendre directement de la structure de printemps. n'importe quoi qui peut injecter les dépendances appropriées (théoriquement) fonctionnera aussi bien.
Il y a des années, il y avait cette bête d'EJB, qui était très "intrusive". Le printemps a été suspendu d'être un ensemble beaucoup plus simple de cours d'assistance, et c'était plus comme des bibliothèques que des cadres.
Aujourd'hui, le printemps devient la nouvelle bête. En tant qu'entreprise de milliards de dollars, il est dans leur intérêt de verrouiller les gens. Oui, bien sûr, vous n'avez pas de problème de dépendance et vous pouvez quitter le printemps à tout moment.
avec EJB, au moins vous avez quelques fournisseurs à choisir.
Si c'était une question, je voterais pour le fermer comme "subjectif et argumentatif". La question a demandé une définition de «non intrusif». Contrairement aux "bêtes" (tout ce que vous voulez dire par cela) n'est pas utile.
par bête, je veux dire grand lourd moche et intrusif . Si les fanboys de printemps ont un problème avec ce mot, ils devraient peut-être consulter le livre de printemps d'origine et voir comment le ressort décrit EJB.
Il est parfaitement possible d'utiliser Spring sans dépendances directes sur le cadre du printemps dans votre code d'application. Cela ne signifie pas le code continue de fonctionner sans ressort, étant donné que la fonctionnalité fournie par le printemps devra être remplacé par un autre conteneur IoC ou un code qui instancie directement tous les objets dans une chaîne de dépendance, mais cela signifie que vous pouvez choisir de choses câbler avec ressort, ou par un autre mécanisme.
Cependant, pour être vraiment unintrusive avec le printemps, vous devez garder tout votre extérieur de votre code de configuration, ce qui signifie en utilisant XML pour tout. Cela fonctionne à merveille au printemps, mais sa douleur dans le cou pour les développeurs et, depuis l'avènement de l'utilisation généralisée des annotations en Java 5, ne sont pas vraiment la façon java. Ainsi, le printemps fournit beaucoup d'annotations pour les choses du câblage ainsi que directement dans votre code. Cela peut évidemment créer des dépendances sur Spring dans le code, bien que toutes les balises de printemps sont résolus au moment de la compilation, de sorte que vous pouvez toujours exécuter vos cours en dehors d'un contexte de printemps, sans aucune dépendance sur des pots de printemps et autres. De plus, chaque fois que possible, les annotations de printemps sur mesure ont été remplacés par des annotations JEE génériques. Avec Spring 3, il est vraiment très facile à utiliser seulement des annotations JEE ainsi qu'une quantité limitée de XML pour initialiser le contexte d'application.
La beauté du chemin du printemps de faire les choses est que la fonctionnalité sous-jacente qui implémente une fonctionnalité peut souvent être sélectionné lors de l'exécution. Si vous utilisez un système ORM dans un conteneur non géré pour le développement, en utilisant un gestionnaire de session natif, vous pouvez facilement passer à conteneurs sessions gérées dans la production sans changer de code que ce soit si vous avez configuré l'application pour permettre la gestion des transactions de poignée de ressort. Les méthodes qui sont marquées comme @Transactional prendront automatiquement une session et de transaction, quelle que soit la source, sans aucune modification du code. En fait, vous pouvez trivialement passer à un tout autre cadre ORM, si vous êtes si incliné, bien que ce soit un cas d'utilisation assez rare, en vérité, si la plupart des applications ont tendance à avoir cadre ORM code spécifique et / ou requêtes dans leur accès aux données code.
La différence entre le printemps et une ancienne cadre « intrusive » est que les cadres intrusives nécessitent souvent de mettre en œuvre des interfaces particulières ou, pire encore, vous forcer à hériter des classes de base en particulier, pour la fonctionnalité cadre d'accès. Dans ce dernier cas, non seulement vous avez une dépendance sur le cadre que vous utilisez, mais il limite fortement la structure de votre hiérarchie de classes, aussi - dans une langue qui ne permet que l'héritage unique. Les versions récentes des EJB tirées de l'élégance du printemps (et d'autres) modèle moins intrusif et EJB lui-même est depuis devenu beaucoup moins intrusive (Il est tout au sujet des POJO).
Je ne vois pas vraiment de soutien à l'argument de irreputable que le printemps est maintenant une bête milliards de dollars qui bloque les utilisateurs. Le printemps, si quoi que ce soit, moins intrusive qu'elle ne l'a jamais été tout en offrant toujours plus de fonctionnalités. Il est certainement possible de vous enfermer au printemps, et beaucoup de devs sont parfaitement disposés à le faire précisément parce que les frais généraux d'exécution de l'utilisation du printemps est si trivialement petit que la plupart d'entre nous ne peut imaginer beaucoup de scénarios dans lesquels nous pourrions retirer printemps à partir d'un projet. Si je veux un environnement JEE entièrement géré, je peux configurer pour que (et exécuter dans le conteneur de tout fournisseur disponible). Si je veux courir dans tomcat ou jetée avec 100% de la configuration et la gestion de l'exécution à venir du printemps, je peux le faire aussi. Je suis donc en général parfaitement heureux d'utiliser une fonctionnalité spécifique à ressort au risque de verrouillage à moins que les exigences du projet interdisent expressément. Le printemps ajoute très peu de frais généraux lors de l'exécution, il est donc un choix à faible risque.
Quand les choses se gâtent, je trouve printemps pour être beaucoup plus facile à apprendre que EJB. Je peux accomplir les mêmes choses avec une ou l'autre méthode, mais il est plus facile d'apporter devs qui sont inexpérimentés si j'utilise Spring par rapport à EJB, donc l'embauche est plus facile, les coûts d'entretien à long terme sont plus faibles, et les cycles de libération sont plus courts. < / p>
L'attrait principal d'un cadre non introductif est qu'il reste à l'écart de vos activités de conception et de modélisation. Il reste complètement à l'écart jusqu'à ce que vous en ayez besoin.
static.springsource.org/spring/ Docs / 3.0.x / ...
Le ressort peut être non intrusiforme, vous pouvez écrire des composants qui n'ont aucune dépendance au printemps. Toutefois, cela nécessite de la DICELLINE et de la réalité, de nombreux projets de printemps introduisent des dépendances au printemps et la manière dont elle se comporte ainsi, de nombreux projets de printemps ne l'utilisent pas comme un conteneur non intrusif.
Sérieusement, comment le diable peut-il ne pas être intrusif? Le développeur peut coder quelle que soit la manière dont ils choisissent et que le cadre magique figure par magie ce qu'ils veulent dire?