Webframeworks : aperçu et classification

Aujourd’hui, toujours plus d’applications de bureau migrent vers le Net. Elles deviennent donc des applications Web disponibles pour les utilisateurs simplement depuis leurs navigateurs. Des exemples classiques sont les webmails ou browser games. Pour les entreprises, le modèle de licence Software-as-a-Service (SaaS) s’est largement établi. Il existe maintenant des applications Web pour gérer sa relation client (CRM), envoyer des newsletters, planifier ses projets, manager son personnel ou encore écrire sa comptabilité. Ainsi, les petites entreprises peuvent bénéficier de modèles adaptés à leurs besoins et accéder à ces services avec une simple connexion à Internet. Les coûts de maintenance et d’administration sont alors minimes et les utilisateurs peuvent bénéficier d’un maximum de flexibilité.

Pour le développement d’applications Web, les programmateurs ont en principe recours à ce que l’on appelle les frameworks Web ou WF pour Web framework en anglais. Mais qu’est-ce qu’un framework exactement ? Et quelle est leur utilité pour les applications Web ?

Sous le terme de framework, on entend une structure qui sert de base pour le développement de logiciels. Pour écrire un nouveau software, commencer tout depuis zéro constituerait une grande perte de temps. Il existe ainsi des solutions pour mettre en place rapidement des fonctions standard de développement, qui s’appuient sur des codes de programmation qui ont fait leurs preuves. En programmation orientée objet, les frameworks sont composés de classes qui servent de structure de construction pour le développement des objets logiciel. Un framework représente différentes classes et constitue ainsi la structure de base de conception des logiciels. Si le framework sert de structure de base pour une application Web, on parle alors de Web application framework (ou plus court : Webframework).

Pour servir de base de développement aux logiciels, les frameworks Web doivent mettre à disposition des structures claires et simples, qui permettent aux développeurs de mettre en place des applications Web en très peu de temps. Pour être facilement utilisables, les frameworks Web doivent normalement être basés sur les 3 grands principes de conception suivants :

• Don’t repeat yourself (DRY) : le précepte don’t repeat yourself recommande d’éviter les redondances dans le développement de votre logiciel. Les informations répétitives, comme les duplications de codes, doivent être évitées car elles ont un impact négatif sur le fonctionnement général du logiciel. Si des portions de codes redondantes doivent être ajustées, de nombreuses modifications vont devoir être effectuées à différents endroits du code de programmation.
  
  
• Keep it short and simple (KISS): simple et court, c’est le principe de base du paradigme KISS. Il repose sur une logique de parcimonie : si plusieurs solutions sont disponibles pour un objet, c’est l’approche qui comporte le moins d’hypothèses et de variables qui sera choisie. Pour utiliser un framework ou résoudre un problème spécifique, il est préférable d’utiliser le moins de code possible.
  
  
• Convention over Configuration: plus les configurations sont nombreuses et plus la prise en main va être laborieuse. Les conventions permettent en revanche de minimiser la complexité des framework Web. Ces derniers doivent ainsi favoriser des processus qui ont déjà fait leurs preuves avec des paramétrages standard, et proposer en option d’autres possibilités de configuration.

Si ces principes de conception sont respectés, les frameworks Web vont apporter de nombreux avantages à votre développement logiciel. L’introduction d’un framework limite toutefois les développeurs. Ces limites structurelles sont parfois perçues comme des inconvénients. Voici un aperçu des avantages et inconvénients des Webframeworks.

En adoptant un framework web, les développeurs visent avant tout à faire des économies de temps et d’argent. L’idée est ainsi de réutiliser des codes. Cela s’appuie sur des fonctionnalités de base comme sur des accès aux banques de données, des templates pour pages Web, des processus de cache ou des fonctions de sécurité, qui sont mis à disposition par le framework sous forme de modules de codes préconçus. De ce fait, il faut investir moins d’effort pour des codes de développement spécifiques d’une nouvelle application Web. Les frameworks Web étant pour la plupart proposés en tant que logiciels libres gratuits, vous n’aurez pas à compter de frais d’achat.

De plus, les frameworks favorisent la génération de codes sources propres. Les parties de programmes disponibles grâce aux frameworks passent pour la plupart par des cycles de développement et sont continuellement optimisées. La communauté se compose donc de testeurs et de co-développeurs. Pour les projets d’une certaine envergure, les failles de sécurité des nouveaux composants sont alors rapidement découvertes et résolues. S’ensuit en général un échange entre développeurs et utilisateurs sur les forums, qui est géré en partie par les équipes support.

Sur le Net, on trouve un nombre important de frameworks pour le développement Web. Ces derniers se différencient grandement en ce qui concerne leurs principes de conception ou la diversité de leurs fonctions. Les frameworks Web peuvent donc être très différents d’un fournisseur à l’autre. Les développeurs se retrouvent ainsi face à de grands dilemmes pour trouver la structure adéquate à leur projet. Il est alors nécessaire de faire des compromis et d’adapter son projet selon les limites du framework. Les framework étant conçus comme solution universelle, les développeurs utilisent dans de très rares cas toutes les fonctions de la structure établie. Selon la conception du framework, une application va parfois comporter plus de code que nécessaire. On parle alors de codeballast.

Comme inconvénient majeur, on note notamment la dépendance des développeurs aux frameworks Web choisis, à un fournisseur spécifique ou à la communauté de développeurs. Suivant les cas, les frameworks sont soumis à des conditions de licence spécifiques. De plus, des problèmes peuvent apparaître lorsque les programmations complémentaires sont mises en place. Pour que les développeurs puissent se familiariser avec les possibilités d’utilisation des programmes et leurs structures, un temps d’adaptation est parfois nécessaire. Ce temps est tout de même à relativiser comparé à celui que vous gagnez en utilisant par la suite les fonctions préconçues et les modules de code. Les détracteurs craignent toutefois que les savoirs de base ne se perdent. En effet, les utilisateurs qui programment uniquement à partir de bases frameworks se penchent vraisemblablement moins sur les langages de programmation utilisés.

Les codes sources de la plupart des frameworks Web étant accessibles librement, chacun a la possibilité de s’en faire une idée. Attention, si pour une entreprise, une application est développée sur la base de modules de codes accessibles de manière libre, l’application va être plus transparente pour les hackers que des applications où le code source n’est pas public. Restez donc vigilants.

Comme tous les frameworks en général, les framework d’application Web utilisent des bibliothèques logicielles (libraries) et outils de développement Web. Alors que les bibliothèques mettent simplement des fonctionnalités uniques à disposition, un framework peut être considéré comme une structure interactive pour processus standardisés, soit une partie presque complète d’application.

Les composants de base d’un framework logiciel utilisent des classes et leurs méthodes associées. Il s’agit ici de blocs de codes qui décrivent les propriétés des objets de logiciels et leurs comportements. Certains de ces composants sont statiques et non modifiables. D’autres peuvent être adaptés par les utilisateurs, comme avec les méthodes. Vous avez même la possibilité d’ajuster la structure de programmation à une mission spécifique. Pour les composants flexibles d’un framework, le nom « Hot Spots » s’est imposé. Les parties statiques sont quant à elles nommées « Frozen Spots ».

Les frameworks Web poursuivent généralement le concept de l’inversion de contrôle (IoC pour l’anglais Inversion of Control). Il s’appuie sur un principe dit d’Hollywood pour la programmation orientée objet, à savoir : « Don’t call us, we call you! » (Ne m‘appelez pas, je vous appellerai »).

Pour simplifier, l’IoC signifie que la prise en charge de l’exécution du programme ne repose pas sur les composants qui sont développés et exécutés sur la base du framework, mais sur le framework lui-même. Ce dernier entreprend les fonctions d’un programme principal qui coordonne les flux de contrôle. D’autres composants, qui sont implémentés par les utilisateurs dans le framework et ainsi enregistrés, sont à disposition si besoin. On peut comparer classiquement ceci à un casting d’Hollywood : « nous savons maintenant qui tu es, et nous reviendrons vers toi si besoin ».

Pour pouvoir exécuter la fonction centralisée de pilotage, les frameworks Web présentent une interface spécifique qui doit être implémentée par tous les composants mis en place. Grâce à ce principe de conception, le framework est en mesure de mouvoir à tout moment les composants installés et d’installer des méthodes de callback. Ceci permet au framework d’injecter si besoin des informations aux composants ou de provoquer un comportement spécifique grâce aux méthodes. Alors que les classes et leurs éléments liés sont bien codés pour les processus classiques de développement de logiciel et donc déjà fixes pour la compilation, le concept d’inversion de contrôle d’un logiciel permet de générer des objets dynamiques pendant le process.

L’IoC est considéré comme un modèle de conception général pour le développement de logiciel. On y trouvera plus spécifiquement les modèles Dependency Injection (également dit injection de dépendance) et Dependency Lookup.

La majorité des frameworks d’application Web se base sur un motif d’architecture appelé Modèle-vue-contrôleur (MVC). Ce dernier vise à une séparation stricte de la logique d’application et de couches de présentation et se décompose en trois domaines, à savoir le modèle, la vue et le contrôleur.

• Modèle : le modèle est la partie du framework qui comporte les données à afficher, ainsi que la logique d’application et les règles. Les modifications que vous souhaitez effectuées sont exécutées avec la méthode dédiée.
  
  
• Vue : ce module a pour mission de représenter les données procurées par le modèle. Ainsi, la vue sollicite le statut du modèle par la méthode et est informée des modifications. Une autre tâche de la vue est de recevoir les entrées utilisateurs (touches, clics de souris) et de les transférer au contrôleur.
  
  
• Contrôleur : le contrôleur constitue l’interface entre le modèle et la vue. Il gère ici une ou plusieurs vues, analyse les entrées utilisateurs et réagit en conséquence, par exemple en transmettant des données au modèle ou des modifications à la vue.

Le motif d’architecture du MVC correspond en quelques sortes à un principe d’organisation de code. La séparation des responsabilités modèles, vues et contrôleurs permet de simplifier les modifications futures, les extensions mais aussi les réutilisations de chaque composant. Le temps de programmation est ainsi considérablement réduit pour adapter par exemple un logiciel à différentes plateformes (Windows, Mac, Linux), car seul le contrôleur et l’affichage doivent être ajustés.

Les motifs de conception arrivent sous la forme de JSP (Java Server Pages) -Model-2, même pour les Webframeworks basés Java. Ainsi, une page JSP correspond à la vue, une servlet au contrôleur et un Java Bean au modèle.

Le marché pour les applications Web est très varié. Les applications à disposition des utilisateurs sur un navigateur se différencient selon les domaines et la diversité de leurs fonctions, pas seulement en termes de taille et d’apparence mais aussi au niveau de la conception du logiciel. Ceci est dû à la diversité des frameworks Web à disposition, car ces derniers s’appuient sur différentes technologies et différentes approches de conception software. Se confrontent les approches multipages et monopages, les approches centrées serveur ou client, ou encore les frameworks Web basés sur les actions ou sur les composants.

Les applications à multiples pages reposent sur des pages HTML, qui peuvent en principe être ouvertes en entrant leur URL dans le navigateur, et qui sont liées par des liens hypertextes. L’interface utilisateur d’une application monopage repose en revanche sur une seule et unique page HTML, sur laquelle différentes données utilisateurs s’affichent. L’URL d’une application monopage ne change pas au cours de la navigation.

Le modèle de programmation des applications Web classiques se réfère à celui du World Wide Web, dont l’architecture s’appuie sur l’HyperText Transfer Protocol (HTTP). Si une application est ouverte par un utilisateur, un ou plusieurs serveurs ainsi qu’un programme client (en général un navigateur Web) vont être impliqués. Suivant la manière dont la communication entre le serveur et le client est établie, on pourra parler d’application centrée serveur ou client.

• Orienté client : si au démarrage d’une application, l’ensemble de l’interface utilisateur HTML avec sa logique d’application est chargé pour le client, on parlera d’application centrée client. Les modifications sur l’interface dues aux données utilisateurs sont dans ce cas opérées par des langages de programmation orientés client comme Javascript. L’approche client intervient dans un premier temps pour le développement d’applications monopages et sont suivies par des frameworks Javascript comme AngularJS [En savoir plus sur AngularJS sur angularjs.org] (https://angularjs.org/) ou EmberJS [vers le site de EmberJS] (http://emberjs.com/).
  
  
• Orienté serveur : pour les applications côté serveur, la logique d’application se concentre naturellement sur le serveur qui crée l’interface utilisateur et la délivre aux clients. Pour les modifications sur l’interface utilisateur, des langages de programmation côté serveur sont également à disposition et le développement est en grande partie indépendant des incertitudes côté client. Cette approche est adoptée en principe pour les applications multipages pour lesquelles des affichages de pages différents vont pouvoir être consultés par le serveur si besoin. Une telle conception implique certes un temps de chargement plus long mais réduit les processus sur l’appareil du client. Pour de nombreuses applications, un transfert de la logique de commande est évité pour des raisons de sécurité. Une approche centrée serveur peut être mise en place avec des frameworks tels que Django, Zend et Ruby on Rails.

Une approche de programmation centrée serveur intervient surtout pour les frameworks qui sont développés selon des structures multipages et des interfaces HTLM classiques. L’interface seule est représentée dans l’application Web et va naviguer en règle générale sur le browser. Les applications Web de la sorte s’exécutent indépendamment du système d’exploitation ou du navigateur Web utilisé. La logique de commande sera gérée par le serveur selon le concept requête / réponse HTML classique.

Les applications Web centrées clients sont parfois désignées comme des rich clients application ou rich internet application (RIA). Ce type d’applications implémente les interfaces utilisateurs avec la logique d’application dans le client. L’interface est en principe complètement chargée au lancement. Contrairement aux applications Web classiques, les serveurs centrés clients permettent de mettre en place certaines propriétés, telles que la commande Drag & Drop, la disponibilité offline et l’accès au disque dur, alors que ces dernières sont plutôt connues des applications de bureau.

Les frameworks Web peuvent être classés en deux catégories sur le plan du pilotage. Alors que les frameworks basés sur les actions (action-based) s’appuient sur le schéma HTTP requête/réponse, le framework Web basé sur les composants (component-based) en fait abstraction. Les frameworks basés sur les actions : avec les frameworks basés sur les actions, le contrôleur sert d’instance centrale, qui accepte les requêtes clients, les valide et envoie une action appropriée. Pour chaque action possible, un objet logiciel qui comprend la logique d’application doit être traité au préalable par le développeur de l’application. L’objet provient alors en principe de classes abstraites. Si l’action est exécutée, le contrôleur actualise le modèle de données et transfère le résultat à la vue qui de son côté génère la réponse et l’envoie au client. Les frameworks Web basés sur les actions s’appuient fortement sur le modèle MVC et peuvent également être appelés « frameworks basés sur les requêtes » du fait de l’introduction strictes du schéma requête/réponse. On trouvera parmi les plus classiques :

• Django
• Ruby on Rails
• Symfony
• Spring MVC
• CodeIgniter

Comme les actions possibles d’un framework Web basé sur les actions est défini par le développeur même, on parle d’approche white box. Elle procure une grande liberté aux développeurs, mais exige toutefois une bonne compréhension des frameworks, car les développeurs prennent en charge les constructions HTML, CSS et JavaScript. Frameworks Web basés sur les composants : Contrairement à l’approche orientée action, les frameworks Web basés sur les composants sortent du schéma réponse/requête HTTP : l’interface utilisateur de l’application Web est considérée comme un regroupement de composants. Pour chacun de ces composants qui sont reliés aux objets logiciels du côté serveur, des réactions précises sont définies pendant le développement de l’application Web. Elles succèdent à des événements provoqués par une interaction utilisateur avec un composant. On parle de ce fait également de Webframeworks orientés événements. Des exemples classiques sont :

• Lift 
• Apache Tapestry
• JavaServer Faces
• Apache Wicket

L’idée de base dans l’approche basée sur les composants est de grouper les actions apparentées. Un composant AccountController représente par exemple des actions comme login, logout ou getAccount. Un objet logiciel peut par conséquent être responsable de plusieurs actions. Les frameworks Web basés sur les composants proposent en règle générale un grand choix de composants réutilisables, qui dissimulent au développeur les détails du schéma réponse/requête sous-jacent. On parle alors de Black box. Les webframeworks de ce type sont donc appropriés aux développeurs qui souhaitent s’appuyer dans un premier temps sur des composants prédéfinis. Pour avoir en revanche plus de liberté en HTTP, HTML, CSS et JavaScript, un framework Web basé sur les actions est en revanche davantage conseillé.

Les framework ayant une grande influence sur les fonctions et possibilités de conception de l’application Web ainsi que sur votre workflow, le choix d’une structure de programmation appropriée va être la première des grandes étapes de votre travail. Cette décision va dépendre de votre projet et de vos connaissances techniques.

Il est fondamental de poser des questions sur le type d’application et l’architecture que vous souhaitez mettre en place (centré serveur ou client). Ces deux aspects vont avoir un impact direct sur l’utilisation et l’intuitivité de votre application Web pour les utilisateurs.

Vos connaissances en langage informatique et la disponibilité des infrastructures nécessaires vont également être à prendre en compte dans votre recherche de framework Web. Pour les langages de programmation largement utilisés comme PHP (par exemple Zend, Symfony, CakePHP ou CodeIgniter), Java (par exemple JavaServer Faces ou Apache Wicket) ou Python (par exemple Django), il existe un large choix de webframeworks bien documentés. Quant à Ruby, sa popularité dans le monde de la programmation se doit à Ruby on Rails vers lequel de nombreux développeurs se sont tournés. Les frameworks Web centrés clients utilisent en revanche le plus souvent le langage de script JavaScript.

Les développeurs, qui ont par le passé programmé dans un premier temps des applications bureau, trouvent souvent le framework orienté action sur le schéma requête/réponse plus complexe qu’un développeur Web classique. Dans ce cas, un framework basé composants peut faciliter leur approche.