Framework, vous avez dis Framework ?

Pourquoi mettre en place un Framework ?

     1.            Introduction

De nos jours, le terme Framework technique ou Framework d’entreprise sont devenus populaires, cependant bon nombre de personne n’en comprennent pas les tenants et les aboutissants. Ce petit document va tenter de résumé ce que ces termes sous entendent, ce que ces deux type de Framework peuvent apporter.

     2.            Définition

2.1            Framework technique

Un Framework technique est un ensemble de librairies permettant de réaliser un ensemble de fonctionnalité n’ayant pas attraie à un métier particulier. Par exemple une librairie d’authentification au travers d’un LDAP Novell trouve sa place dans un tel Framework. Il est souvent composé de fonctionnalités développées de toutes pièces ainsi que de librairie récupérées tel quel sur internet.

2.2            Framework d’entreprise

Un Framework d’entreprise est quand à lui axé sur le métier de l’entreprise, il va en fait normaliser le moyen pour toutes les applications de l’entreprise d’utiliser une partie du métier de celle-ci. Par exemple une banque va placer dans un Framework d’entreprise la définition d’un compte bancaire et un service permettant de le manipuler. Ainsi toutes les applications de la banque pourront accéder aux informations du compte bancaire d’un client en utilisant ce Framework.

     3.            Avantage d’un Framework

Les Frameworks apportent de nombreux avantages :

Ø  Standardisation du code

Le fait d’utiliser un Framework assure que tous les développeurs utiliseront la même API, en effet, reprenons l’exemple de notre banque, sans Framework probablement que chaque application aura sa propre méthode de récupération des informations d’un compte bancaire. Le nom de cette méthode peut être différent d’une application à une autre, mais la technologie sous jacente peut aussi être différentes (Accès direct à la base de données, utilisation d’un Web Service, …). Autant de possibilité qui font qu’utiliser une ressource sur deux projets nécessite un temps d’adaptation à chaque switch. Le Framework lui propose une seule méthode, les détails techniques étant laissé aux Frameworks, un développeur peut donc passer d’un projet à un autre sans avoir à s’adapter au code « technique » du projet et donc ce concentrer sur les traitements métier de l’application.

Ø  Correction de bug pour l’ensemble des applications

En effet si toutes les applications accèdent à une seule méthode pour effectuer un traitement, si ce traitement ne fonctionne pas correctement ou doit être modifié, il suffit d’apporter les modifications au Framework. Ainsi toutes les applications utilisant le Framework seront modifiées en une seule fois.

Ø  Modularité & flexibilité

Les bons Framework sont toujours architecturer pour permettre une grande souplesse, ils implémentent de nombreux patterns qui leur permettent d’apporter une finesse bien supérieure à celle d’une application classique, par exemple, les Frameworks apportant une librairie d’accès aux données implémentent souvent un ensemble de providers différents (ODBC, SQL Server, Oracle) le plus souvent avec un choix du provider à utiliser par le biais du fichier de configuration. Une application elle va se limiter au mieux à une classe abstraite dans la couche d’accès aux données évitant l’initialisation de la connexion, ou la gestion des erreurs.

Ø  Productivité

Les Frameworks permettent un gain de productivité  à long terme sur les  équipes de développement, en effet une fois qu’un développeur à l’habitude d’utiliser le Framework, il peut passer d’un projet à un autre en un temps plus court. De plus comme chaque équipe n’a pas à recréer les classes techniques  déjà présentes dans le Framework  elle peut se concentrer sur les fonctionnalités propres à l’application.

Ø  Optimisation

Il est plus simple d’apporter des optimisations sur le code d’un Framework que de placer ces optimisations dans l’ensemble des applications. Ce type de modifications étant souvent très couteuses, on rechigne à les faire sur une application, mais finalement lors que le Framework est optimisé cela profite à l’ensemble, ce qui réduit le cout pour chaque application.

     4.            Désavantage d’un Framework

Rare sont ceux qui le disent, mais un Framework n’est pas la solution magique qui convient à tous. En effet, les Frameworks comportent aussi leur lot de désavantage :

Ø  Cout élevé

Le développement d’un Framework coute plus cher que le développement des fonctionnalités techniques  équivalentes dans une application. En effet, un Framework doit prendre en compte l’ensemble des cas d’utilisation d’une fonctionnalité alors qu’une application n’implémentera que les cas d’utilisation lui étant propre.

Ø  Niveau de complexité

Le fait de devoir penser à l’ensemble des cas d’utilisation et le fait de systématiquement penser de manière générique n’est pas donné à tous. De plus, le Framework résout souvent des problématiques complexes demandant une connaissance poussé de la technologie utilisée.

     5.            Quel choix faire ?

Au vu des deux chapitres précédents, je dirais qu’un Framework n’a pas sa place lorsqu’il est utilisé par un petit nombre d’applications, il prend tout son sens lors de la mise en place d’une standardisation dans une entreprise avec de nombreux projets en développement. Le type de Framework reste à définir selon les besoin de chacun, les sociétés de service choisiront d’implémenter un Framework technique alors que les grands groupes préféreront la mise en place de Framework d’entreprise (métier). Le choix est plus une question de contexte et de réutilisabilité d’un projet à l’autre.

     6.            Comment aller encore plus loin ?

La mise en place un Framework est un gain évident pour certains, mais un Framework seul ne peut pas assurer les gains de productivité nécessaire à la réussite des projets d’une entreprise. Il est possible d’optimiser encore plus le processus de développement pour les grandes entreprises.

6.1            Génération de code

La mise en place de modèles pour un générateur de code type SmartCode ou CodeSmith peuvent éviter au développeur les parties du code répétitives et rébarbatives. Par contre leur souplesse reste encore limitée, en effet un générateur de code va écrire vos classes d’accès aux données ou votre business model par rapport à une base de données, cependant il faudra souvent repasser derrière pour personnaliser le code.

6.2            GAT et GAX

Les outils « Guidance Automation Toolkit  » et « Guidance Automation eXtensions » permettent de créer et d’utiliser des assistants pour Visual Studio. Par exemple, un assistant permettant de créer une solution structurée en couche avec l’ensemble des projets et les bonnes références dans chacun d’entre eux peut considérablement accélérer la mise en place d’un nouveau projet. Puis une série d’assistants peut vous permettre d’ajouter un projet dans la solution suivant la couche à laquelle il appartient. Enfin d’autres assistants peuvent vous permettre d’ajouter une classe ou une méthode dans celle-ci sans effort.  Ces outils sont très efficaces, cependant ils ne sont toujours pas suffisants. Pour obtenir un environnement encore plus productif, il faudra mettre en place des DSL.

6.3            DSL

Les « Domain Specific Language » permettent d’ajouter dans Visual Studio 2005 un ensemble de designers supplémentaires, Comme le designer de classe de Visual Studio, ils peuvent être bi directionnels. Ils vous permettront une utilisation transparente de votre Framework, par exemple imaginons un DSL permettant de modéliser votre Business Model, chaque fois que vous ajouterai une entité à votre diagramme, un fichier source sera crée pour celle-ci, il contiendra une classe implémentant les bonnes interfaces et héritant d’une classe de votre Framework. Pour chaque propriété, il ajoutera le code nécessaire au DataBinding, etc. Ces outils sont très puissants, malheureusement leur conception n’est pas aisé et demande un temps considérables.

     7.            Conclusion

J’espère que suite à ce petit document, vous avez une vision plus clair des pré-requis à la mise en place d’un Framework ainsi que les possibilités en découlant. Un Framework n’est pas un chantier simple à mettre en œuvre  et plus encore qu’une application nécessite une équipe de haut niveau. Trop souvent, j’ai vu des projets échoués à cause d’une démarche Framework non justifier ou mal gérée (autant en termes de moyen que de compétence). Il faut donc bien réfléchir avant de se lancer dans la démarche et une fois décidé se donner les moyens de réussir.