Est-il possible de refactoriser une application Spring MVC pour utiliser un autre framework MVC?

Question

Je commence juste à utiliser Spring et je suis en train de lire Spring in Action pour accélérer. En citant les avantages du printemps contre EJBs, le livre fait la déclaration:

« Avec le printemps, les composants sont généralement pas nécessaire de mettre en œuvre, étendre ou utiliser des classes spécifiques de printemps ou interfaces, ce qui il est possible de réutiliser les composants n'importe où, même en l'absence de printemps. "

Mon application utilise actuellement Spring MVC. Je peux voir comment la déclaration ci-dessus est vraie pour la logique métier de mon application, car l'utilisation de l'injection de dépendance a complètement découplé nos beans du framework Spring. Mais qu'en est-il des trucs MVC, qui dans ce cas est une application web? Je suis curieux de savoir s'il serait possible d'échanger Spring MVC dans ma demande avec un autre cadre MVC à l'avenir.

Ma question est double:
1) Dois-je voir le niveau Web comme étroitement couplée au cadre de printemps et supposons qu'un changement dans mon MVC nécessiterait la création d'une nouvelle application Web pour le soutenir?

2) Si ce n'est pas le cas, que faudrait-il faire pour découpler l'application Web de Spring? Je peux déjà deviner qu'en l'absence du framework Spring, toutes les annotations devront être supprimées des contrôleurs et le code associé devra être refactorisé pour supporter le nouveau framework MVC.

Je suis particulièrement intéressé par les idées de ceux qui ont vécu ce processus.

Answer 1

Bonne question. Comme vous l'avez souligné à juste titre, le framework MVC a tendance à coupler votre code avec l'API Spring de manière beaucoup plus proche qu'avec les couches de logique métier.

Ceci est quasiment inévitable, bien que dans une moindre mesure qu'avec Spring 3, où les annotations sont très utilisées pour mapper les requêtes aux contrôleurs, et ainsi de suite. Le couplage des paramètres de méthode et des valeurs de retour à l'API Spring est très réduit. Les contrôleurs peuvent s'exprimer en termes de logique métier. Cependant, afin d'obtenir toute sorte d'énergie expressive de Spring MVC, une certaine utilisation de son API va généralement être impliquée. Donc pour répondre à votre question, alors que le couplage de l'API Spring au code de votre contrôleur est assez minime, il est là et devrait être supprimé. Cependant, comme il s'agit d'une API très peu invasive, il devrait y avoir peu de compromis de conception dans votre code, ce qui facilite l'adaptation à un autre framework.