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
Anonymous # 3. October 2009, 08:40
Utiliser windev est en soi une erreur.
Groumphy # 4. October 2009, 06:52
Quant au fait d'utiliser Windev, je ne pense pas que ce soit une erreur. L'erreur est plutôt la politique commerciale de l'entreprise en place de la philosophie logicielle.
Windev est un outil supplémentaire à un développeur afin d'attaquer des domaines multiples tout en ayant une facilité de développement.
Mais la politique commerciale de l'entreprise est plutôt : tout le monde peut développer s'il utilise Windev.
Là se pointe la grosse erreur: tout le monde ne peut pas développer avec qualité, standardisation etc. etc. Par contre en effet tout le monde peut créer très facilement un exécutable.
De ce fait, Windev n'est pas un mauvais logiciel. Il a une mauvaise réputation en cause de sa politique commerciale. Mais là tu t'attaque à la base de l'entreprise PC Soft même. Le propriétaire de PC Soft possède trois sociétés: une immobilière, une IT, une marketing. L'IT étant cliente de la marketing voila le problème: un conflit interne.
Mais de cela on peut débattre des heures... Sans avoir de réels positifs.
En espérant toutefois que l'article sur le framework t'aie plus tout en ayant dans l'esprit qu'il n'y a pas de mauvais logiciel, seule une mauvaise philosophie quelque part.
G.