Framework, utilisation globale
Saturday, 3. October 2009, 05:54:13
J’ai pu suivre récemment une formation d’un AGL (dénommé Windev pour ceux qui n’étaient pas au courant 
) et aussi la manière d’utilisation d’un framework par une application.
En règle générale il y a 3 méthodes d’utilisation :
L’extériorisation : l’application dispose de son framework à coté d’elle et pointe directement dessus et c’est le cas pour chaque application qui dispose de son propre framework. L’avantage est que nous pouvons personnaliser le framework pour l’application en soi, l’alléger ou l’alourdir pour l’application etc. etc. Le désavantage est la multiplication de celui-ci et la maintenance de ceux-ci (au vu qu’ils sont différents). La maintenance peut être pourvue d’une documentation afin de faciliter tant l’utilisation que la fonctionnalité…
La centralisation : toutes les applications utilise un même framework qui se trouve à un endroit sur un serveur, toutes le contenu s’y trouve et chaque application l’attaque. Peu importe qu’il utilise le composant, la DLL, ou autre… Tout s’y trouve.
La maintenance s’en retrouve facilitée mais le développement pur et dur est quant à lui plus complexe. Nous devons bien entendu nous assurer que le framework est compatible toutes version descendante tout en le mettant à jour régulièrement avec de nouvelles entrées et composants.
L’encapsulation : le framework est dans l’application et au moment d’ouvrir l’application, celui-ci est décompressé dans un endroit temporaire du disque dur. Cela sous-entend bien sur que l’application à droit d’écriture etc. L’inconvénient est les droits applicatifs, la maintenance d’évolution (il faut mettre à jour tout d’une traite) et bien entendu le poids !
Quelle est la méthode idéale pour bien faire ? Chacune ont leurs avantages comme leurs désagréments !
Je pense d’une manière générale que s’il s’agit d’une application interne le framework extériorisé dans le répertoire application est le plus simple, s’il s’agit d’un groupe d’application à faible potentiel évolutif et utilisant une même base de programmation la centralisation est le plus simple (toujours dans le cas d’une application d’entreprise) ; dans le cas d’une application livrée à un client, l’encapsulation peut facilement se montrer la solution de facilité, tout en ayant précisé les dépendances bien sûr !
Mais faut-il absolument utiliser un framework ? C’est la question qu’il faut se poser aussi… Principalement que ceux-ci sont propriétaires (Microsoft, PC Soft, etc.) (bien que de nombreux repose aussi sur des technologies libres). N’est-ce pas se restreindre ou se limiter dans la fonctionnalité ?
Pour répondre facilement : le cas où le framework est distribuable librement et utilisable de cette même manière je dirais oui, l’utilisation n’est pas bloquante… Mais que faire si on n’est pas le propre mainteneur du dit framework ?
) et aussi la manière d’utilisation d’un framework par une application. En règle générale il y a 3 méthodes d’utilisation :
L’extériorisation : l’application dispose de son framework à coté d’elle et pointe directement dessus et c’est le cas pour chaque application qui dispose de son propre framework. L’avantage est que nous pouvons personnaliser le framework pour l’application en soi, l’alléger ou l’alourdir pour l’application etc. etc. Le désavantage est la multiplication de celui-ci et la maintenance de ceux-ci (au vu qu’ils sont différents). La maintenance peut être pourvue d’une documentation afin de faciliter tant l’utilisation que la fonctionnalité…
La centralisation : toutes les applications utilise un même framework qui se trouve à un endroit sur un serveur, toutes le contenu s’y trouve et chaque application l’attaque. Peu importe qu’il utilise le composant, la DLL, ou autre… Tout s’y trouve.
La maintenance s’en retrouve facilitée mais le développement pur et dur est quant à lui plus complexe. Nous devons bien entendu nous assurer que le framework est compatible toutes version descendante tout en le mettant à jour régulièrement avec de nouvelles entrées et composants.
L’encapsulation : le framework est dans l’application et au moment d’ouvrir l’application, celui-ci est décompressé dans un endroit temporaire du disque dur. Cela sous-entend bien sur que l’application à droit d’écriture etc. L’inconvénient est les droits applicatifs, la maintenance d’évolution (il faut mettre à jour tout d’une traite) et bien entendu le poids !
Quelle est la méthode idéale pour bien faire ? Chacune ont leurs avantages comme leurs désagréments !
Je pense d’une manière générale que s’il s’agit d’une application interne le framework extériorisé dans le répertoire application est le plus simple, s’il s’agit d’un groupe d’application à faible potentiel évolutif et utilisant une même base de programmation la centralisation est le plus simple (toujours dans le cas d’une application d’entreprise) ; dans le cas d’une application livrée à un client, l’encapsulation peut facilement se montrer la solution de facilité, tout en ayant précisé les dépendances bien sûr !
Mais faut-il absolument utiliser un framework ? C’est la question qu’il faut se poser aussi… Principalement que ceux-ci sont propriétaires (Microsoft, PC Soft, etc.) (bien que de nombreux repose aussi sur des technologies libres). N’est-ce pas se restreindre ou se limiter dans la fonctionnalité ?
Pour répondre facilement : le cas où le framework est distribuable librement et utilisable de cette même manière je dirais oui, l’utilisation n’est pas bloquante… Mais que faire si on n’est pas le propre mainteneur du dit framework ?
WIDGETIZE