Pourquoi le framework Spring est-il appelé "non intrusif"?

Question

L'armature de ressort est NON-INTRUSIVE.

Pouvez-vous élaborer cela?

Merci :) Vous

Answer 1

Ici, "non intrusive" signifie que votre code d'application ne doit pas dépendre du framework Spring directement. Quelque chose qui peut injecter les dépendances appropriées fonctionnera (théoriquement) tout aussi bien.

Answer 2

il y a quelques années, il y avait cette bête EJB, qui était très "intrusive". Le printemps était considéré comme un ensemble beaucoup plus simple de classes auxiliaires, et il ressemblait plus à des bibliothèques qu'à des cadres.

aujourd'hui, le printemps devient la nouvelle bête. En tant qu'entreprise d'un milliard de dollars, il est dans leur meilleur intérêt d'enfermer les gens. Oui, bien sûr, vous n'avez pas de problème de dépendance, et vous pouvez quitter le printemps n'importe quand.

Avec EJB, vous avez au moins quelques fournisseurs à choisir.

Answer 3

Il est parfaitement possible d'utiliser le ressort sans aucune dépendance directe sur le cadre de ressort dans votre code d'application. Cela ne signifie pas que le code continuera à fonctionner sans ressort, puisque la fonctionnalité fournie par Spring devra être remplacée par un autre conteneur ou code IoC qui instancie directement tous les objets dans une chaîne de dépendance, mais cela signifie que vous pouvez choisir de câbler les choses avec le printemps, ou via un autre mécanisme. Cependant, pour être vraiment discret avec le printemps, vous devez garder toute votre configuration en dehors de votre code, ce qui signifie utiliser le XML pour tout. Cela fonctionne magnifiquement au printemps, mais c'est une douleur dans le cou pour les développeurs et, depuis l'avènement de l'utilisation généralisée des annotations dans Java 5, ce n'est pas vraiment la façon Java. Donc le printemps fournit beaucoup d'annotations pour le câblage des choses directement dans votre code. Cela peut évidemment créer des dépendances sur Spring dans le code, bien que toutes les balises Spring soient résolues au moment de la compilation, de sorte que vous pouvez toujours exécuter vos classes en dehors du contexte printanier sans aucune dépendance sur les jarres printanières et autres. De plus, dans la mesure du possible, les annotations de printemps personnalisées ont été remplacées par des annotations JEE génériques. Avec Spring 3, il est vraiment très facile d'utiliser uniquement des annotations JEE plus une quantité limitée de XML pour initialiser le contexte de l'application.

La beauté de la manière printanière est que la fonctionnalité sous-jacente qui implémente une fonctionnalité peut souvent être sélectionnée 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 basculer vers des sessions gérées par conteneur en production sans modifier le code si vous avez configuré l'application pour gérer la gestion des transactions. Les méthodes marquées comme @Transactional capturent automatiquement une session et une transaction, quelle que soit la source, sans aucune modification du code. En fait, vous pouvez facilement basculer vers un framework ORM complètement différent, si vous le souhaitez, bien que ce soit un cas d'utilisation assez rare, donc la plupart des applications auront tendance à avoir un code spécifique ORM et/ou des requêtes dans leur accès aux données code. La différence entre le framework Spring et un framework «intrusif» démodé est que les frameworks intrusifs nécessitent souvent de mettre en œuvre des interfaces particulières ou, pire encore, de vous forcer à hériter de classes de base particulières pour accéder aux fonctionnalités du framework. Dans ce dernier cas, non seulement vous avez une dépendance par rapport au framework que vous utilisez, mais cela limite aussi fortement la structure de votre hiérarchie de classes - dans un langage qui ne permet qu'un seul héritage. Les versions récentes d'EJB ont appris de l'élégance du modèle moins intrusif de Spring (et des autres) et l'EJB lui-même est depuis devenu beaucoup moins intrusif (tout tourne autour des POJO).Je ne vois vraiment aucun soutien pour l'argument irréfutable que le printemps est maintenant une bête de milliard de dollars qui bloque les utilisateurs po Printemps est, si quelque chose, moins intrusif que jamais tout en offrant toujours plus de fonctionnalités. Il est certainement possible de s'enfermer dans le printemps, et beaucoup de développeurs sont parfaitement disposés à le faire précisément parce que le temps d'exécution de l'utilisation du ressort est si petit que la plupart d'entre nous ne peuvent pas imaginer beaucoup de scénarios dans lesquels ressort d'un projet. Si je veux un environnement JEE entièrement géré, je peux configurer pour cela (et exécuter dans le conteneur de n'importe quel fournisseur disponible). Si je veux exécuter Tomcat ou jetty avec 100% de configuration et de gestion d'exécution venant du printemps, je peux le faire aussi. Je suis donc parfaitement heureux d'utiliser des fonctionnalités spécifiques au ressort au risque de blocage, à moins que les exigences du projet ne l'interdisent spécifiquement. Le printemps ajoute très peu de frais généraux à l'exécution, donc c'est un choix à faible risque.

Lorsque l'on se bouscule, je trouve que Spring est beaucoup plus facile à apprendre que EJB. Je peux accomplir les mêmes choses avec l'une ou l'autre méthodologie, mais il est plus facile d'amener des développeurs inexpérimentés si j'utilise Spring par rapport à EJB, donc l'embauche est plus facile, les coûts de maintenance à long terme sont plus bas et les cycles de release sont plus courts.

Answer 4

L'attrait principal d'un cadre non intrusif est qu'il reste hors de portée de vos activités de conception et de modélisation. Il reste complètement à l'écart jusqu'à ce que vous en ayez besoin. Le ressort peut être non intrusif, ce qui signifie que vous pouvez écrire des composants qui ne dépendent pas du ressort.