Est-il possible de coupler librement une application à son framework?

Disons que je développe une application Web. Mon premier choix est d'utiliser PHP avec Fat-Free Framework (F3) et le modèle MVC. L'année prochaine, je déciderai peut-être de passer à Zend Framework, ou peut-être même ASP.NET MVC. Est-il judicieux d'essayer de concevoir mon application de manière à ce qu'elle soit vaguement couplée à son cadre, ou le cadre est-il trop intégré pour le rendre réaliste?

La seule raison pour laquelle je pose la question, c'est parce que cela est apparu récemment dans une conversation avec un pair, qui a critiqué mon idée dans le ciel de coupler librement mon application à F3.

Le couplage lâche de votre application à son framework signifie essentiellement que vous allez écrire un framework proxy. Écrire ce framework proxy demande beaucoup de travail, et si vous passez à un nouveau framework, vous devrez faire beaucoup de travail pour que le framework proxy prenne en charge le nouveau framework. Bien sûr, différents cadres utilisent des idiomes et des modèles différents, ce qui rendra le cadre proxy soit très complexe (si vous essayez de l'adapter à tout) ou très limité (si vous optez pour le plus petit dénominateur commun). Quoi qu'il en soit, vous devrez lutter avec ce cadre proxy.

La capacité de changer de cadre sur un coup de tête vaut-elle tous ces ennuis? Comme je l'ai dit, vous ne pourrez pas le changer sur un coup de tête, car vous devrez ajuster le cadre proxy, ce qui pourrait s'avérer être plus de travail que d'ajuster directement le code d'application.

Ne peut faire.

Vous pouvez concevoir de manière portable sur tous les frameworks. MVC est MVC, et les principes sont à peu près les mêmes quel que soit le langage ou la plateforme utilisé.

Le code réel, cependant, va être très dépendant du framework ou du langage. La seule façon de s'en abstenir serait de coder sur la base d'un framework intermédiaire. Ensuite, vous pouvez avoir le changement d'implémentation intermédiaire (de F3 à .NET?) Sans changer l'application. Ce qui représente beaucoup de travail, suppose des abstractions non fuites et déplace simplement le problème sans le résoudre: vous êtes maintenant lié à votre framework intermédiaire.

Sur une note plus positive: envisagez d'exprimer certains de vos tests (style BDD) dans une plateforme indépendante de votre implémentation. Ceux-ci pourraient survivre à des réécritures majeures.

J'ai vu une fois Robert C. Martin donner une conférence où il a dit quelque chose comme "la première décision que vous prenez est la plus difficile à changer plus tard".

Donc, mon conseil est d'essayer de retarder cette décision si vous n'êtes pas encore sûr de ce que vous voulez utiliser. Identifiez les éléments que vous pouvez définir maintenant et qui resteraient facilement indépendants du cadre que vous utiliserez.

Le verrouillage du framework peut être un problème sérieux, mais il permet de considérer le problème comme un problème de portabilité. La portabilité n'est pas un attribut absolu, mais relative à votre point de départ et où vous voudrez peut-être aller. Par analogie, le logiciel n'est portable que dans la mesure où vous l'avez déjà porté sur d'autres environnements.

La plupart du développement d'une application à l'intérieur d'un framework a tendance à être du code glue, ce qui lie les composants de votre framework. Les fichiers de configuration peuvent faire abstraction d'une certaine quantité de colle dans certains systèmes, mais de nombreux détails doivent être faits dans le code.

D'un autre côté, les règles et processus métier peuvent être extraits de l'application. La partie difficile de l'abstraction est lorsque les règles sont mises en œuvre directement par le cadre; la sécurité, l'accessibilité et le séquençage des processus ont tendance à être appliqués par votre infrastructure et peuvent être les plus difficiles à voir.

Si vous pouvez séparer la partie colle de votre application de la partie règle métier et processus métier et données métier, vous pourrez rendre certaines parties de votre solution portables.