Dans cet article nous avons énuméré les avantages de l’architecture MVC aussi bien pour les performances que pour la facilitation de la maintenance et de la répartition des tâches au sein des équipes de développement hautement spécialisées. Nous avons également passé en revue les différents objets Java qui rentrent typiquement dans la construction d’une application de commerce électronique.

Dans le présent article nous allons parler de l’architecture 3 tiers (3 three-tiers) mais en polarisant cette fois-ci l’attention sur les technologies .Net.

Les architectures MVC et 3 tiers comportent toutes les deux une couche de présentation qui comme son nom l’indique gère les interactions frontales avec l’utilisateur et se charge de l’affichage des résultats des traitements réalisés par les couches métiers (appelées également couches d’affaires dans certains livres). La différence fondamentale entre l’architecture 3 tiers et l’architecture MVC se situe au niveau du contrôleur et de la couche de persistance (Data Tier). En effet dans l’architecture MVC un objet intermédiaire appelé contrôleur gère toutes les requêtes entrantes vers l’application et les dirige vers l’objet d’affaires responsable de leur traitement (EJB, Java Bean, Server Control …). Dans cette architecture (MVC), la logique d’affaires et la logique de persistance (conservation et gestion des données) se situent au niveau de la partie Model. En revanche dans l’architecture 3 tiers, la gestion de la persistance est cantonnée dans une couche dédiée (Data) tandis que la logique d’affaires est codée au niveau d’une couche métier (business Tier).

Globalement, ces deux architectures ont pratiquement les mêmes retombées sur les performances, la maintenance et la répartition des tâches. Pour plus de détails à ce sujet, consulter cet  article.

Il n’est pas toujours facile de savoir dans quelle couche de l’architecture 3 tiers il faut coder une fonctionnalité ou implémenter un objet .Net. Dans le présent article nous fournirons quelques points de repères afin d’aider les concepteurs et les programmeurs à mieux délimiter les frontières entre chacune de ces trois couches. Comme dit par ailleurs notre argumentation se fera en tenant compte des possibilités offertes par les technologies ASP.net d’une part et des spécificités des applications de commerce électronique d’autre part.

Il est important que l’affectation des objets et des fonctionnalités à chacune des trois couches se fasse de manière à favoriser leur réutilisation dans le plus grand nombre de scénarios possibles (le principe de réutilisation est d’ailleurs indissociable de toute approche de développement orientée objet). Un découpage et une affectation appropriée des objets ASP.net à chacune des trois couches permet non seulement de construire l’application avec plus de célérité mais facilite également sa maintenance corrective et évolutive.

Le premier point de repère auquel il faut se référer lors de l’éclatement d’une application web en plusieurs couches est sans conteste le langage de programmation utilisé. En effet pour pouvoir programmer une application web professionnelle il faut maîtriser une multitude de langages et technologies (typiquement un langage de balisage pour présenter les informations (HTML), des feuilles de styles pour embellir la partie frontale de l’application (CSS), un métalangage pour structurer les informations (XML), un langage de script côté client pour gérer les interactions de l’utilisateur avec l’interface (Javascript, Vbscript), un langage de script ou un langage de programmation côté serveur pour coder la logique d’affaires et les interactions avec la base de données (VB.net, C# …).

Cette plénitude de langages fait appel à plusieurs profils de développeurs et nécessite une répartition très spécialisée des tâches et des responsabilités (par exemple le webmestre ne doit toucher qu’à la partie DHTML tandis que l’ingénieur .Net ne sera concerné que par la partie C#).

Les environnements de développement intégré comme Visual Studio.net facilitent énormément l’éclatement de l’application en isolant d’entrée de jeu tous les langages servant à l’implémentation de la couche de présentation de ceux qui servent à l’implémentation de la couche d’affaires et de la couche de persistance. En effet dans Visual Studio le code C# ou VB.net est conservé dans des fichiers qui portent respectivement l’extension aspx.cs ou aspx.vb). Le code HTML est pour sa part conservé dans des fichiers ayant l’extension aspx. Le lien entre ces deux types de fichiers se fait à l’aide de l’attribut CodeBehind de la directive @Page (voir l’exemple suivant :)

<%@ Page Language="vb" AutoEventWireup="false" Codebehind="SamplePage.aspx.vb" Inherits="SampleProject.SamplePage"%>

Dans cet exemple, le code Vb.net associé à la page SamplePage.aspx est conservé dans le fichier SamplePage.aspx.vb.

Maintenant que nous avons procédé à une première dissection de l’application en tenant compte du langage de programmation et des domaines de spécialisation des développeurs, nous allons à présent procéder à un deuxième éclatement en prenant en considération les fonctionnalités que permettent d’implémenter les principaux objets d’ASP.net (notamment les ASP.net WebForms, les Master Pages, les classes C# ou VB.net et les Web Server Controls).

Les WebForms sont une catégorie hybride entre les pages web conventionnelles et les Forms de l’environnement fenêtré Windows. Ils permettent de concevoir des interfaces web avec autant de facilité et d’intuitivité qu’on peut concevoir un WinForm. Ils servent donc à créer une interface graphique à travers laquelle l’utilisateur renseigne des informations, sélectionne des options et déclenche des traitements. De ce fait ils doivent se retrouver au niveau de la couche de présentation.

Les Master Pages sont des templates qui peuvent être appliqués à un ensemble plus ou moins restreint de pages ASP.net. De ce fait ils doivent également se retrouver au niveau de la couche de présentation.

Les Web Server Controls sont des classes .Net compilées qui génèrent du code HTML/Javascript/Vbscript à la volée lorsqu’elles sont invoquées par le client. Leur principal attrait c’est qu’on peut agir directement sur leurs méthodes et leurs propriétés à partir du langage de programmation (un peu comme on le fait avec les contrôles de Visual Basic dans les applications fenêtrées non webifiées). Dépendamment du rôle qu’ils jouent dans l’application ils peuvent se retrouver aussi bien au niveau de la couche de présentation qu’au niveau de la couche d’affaires (Par exemple les Web User Control qui sont une catégorie particulière des Web Server Controls doivent se retrouver au niveau de la couche de présentation parce que fondamentalement ils jouent le même rôle que les champs d’un formulaire HTML. La principale différence c’est qu’ils exposent leurs méthodes et propriétés aux langages de programmation .Net. Il est ainsi possible de les invoquer directement sans passer par des scripts clients comme ceux qu’on retrouve dans le modèle DHTML par exemple. En revanche les Server Controls conçus spécialement pour effectuer des traitements spécifiques au domaine de l’application doivent bien évidemment être placés au niveau de la couche d’affaires.


Le schéma suivant situe les différentes composantes d’une application web .Net dans l’architecture 3 tiers.
 

Kamal AOUDA