Blog de Beler Ingénierie

Séparer les problématiques : intêret principal du développement 3-tiers

Pourquoi ? Parce qu’il est plus facile de gérer le développement d’un grand projet en divisant l’application en modules; et donc une équipe de développeurs en sous-équipes, chacune se voyant confier la responsabilité d’un module de l’application.

On peut se passer de cette organisation dans le cadre de petites applications. En revanche, les applications moyennes ou importantes sont pratiquement impossibles à gérer sans appliquer des règles claires.

Avec le temps, on a vu émerger certaines tendances adoptées par l’industrie et dont le but est précisément de gérer la complexité au sein des applications ASP.NET. Mais l’architecture et le développement d’applications ASP.NET modernes et professionnelles ne peuvent être menés à bien sans utiliser les expériences accumulées au fil du temps par la communauté.

WCSF (Web Client Software Factory) : l’alternative

Microsoft a monté une équipe dédiée à la création de modèles pour les architectes d’applications et les développeurs. Le groupe Modèles et Méthodes fournit à la communauté des développeurs ASP.NET professionnels deux frameworks qui capitalisent des années d’expérience des meilleures sociétés de développement au niveau mondial : La Web Client Software Factory (WCSF) et l’Enterprise Library. La façon dont ces deux librairies s’utilisent dans une conception 3-tiers dépend du type de projet. Elles sont en fait complémentaires au modèle 3-tiers, et participent à la tendance actuelle de dépasser une approche purement 3-tiers, vu que la logique d’interface devient de plus en plus encombrée.

Web Client Software Factory propose une alternative à l’organisation induite par ASP.NET MVC, sur les aspects de la testabilité et de la séparation approfondie des problématiques. En prenant en considération le classique ASP.NET (WebForms), on peut parvenir à une modularité raisonnable, en suivant les modèles WCSF, surtout pour les sites Web transactionnels métier (à l’opposé de MVC qui convient mieux aux sites Web orientés contenu).

Le point majeur de la technologie ASP.NET MVC est le concept Model View Controller : il permet de diviser l’interface utilisateur en modules à l’intérieur de couches logiques, supprimant ainsi les fichiers source d’interface utilisateur volumineux, caractéristiques des projets ASP.NET classiques et connus pour la lourdeur de leur maintenance.

Bien que cela ne soit pas aussi simple qu’ASP.NET MVC, l’utilisation du classique ASP.NET conjointement au modèle MVP (Model View Presenter) présente beaucoup d’avantages qui ne doivent pas être négligés pour les projets importants.

S’ils conjuguent cet atelier et leur savoir, les développeurs professionnels ASP.NET en entreprise n’ont plus d’excuse si l’organisation de leurs projets présente des failles : finies les interfaces utilisateurs lourdes, compliquées (où l’essentiel de la logique est intégrée aux fichiers cachés derrière le code des pages aspx) !

C’est ainsi que les efforts faits au début pour structurer le code source deviendront payants : il est désormais possible d’avoir une base de code gérable, comprise par tous les nouveaux développeurs qui viendront rejoindre l’équipe. Elle assure également la cohérence entre projets, où chaque application reposera sur un socle commun.

Comment est-ce lié au 3-tiers ?

3 tiers et MVP (Model View Presenter) sont des modèles complémentaires que l’on retrouve ensemble dans la plupart des projets ASP.NET. Pour obtenir une idée de MVP, voici une cartographie des objectifs des modules dans trois architectures ; 3 tiers physique, 3 tiers logique (du point de vue de l’application) et MVP (le modèle utilisé dans WCSF).

Attention : ce tableau est simplifié à l’extrême afin d’avoir une idée simple du fonctionnement 3-tiers.

Enterprise Library : pour suivre les best practices

Au-delà de la simple séparation de modules en composants 3 tiers, il existe également un autre besoin.
L’autre outil incroyablement utile pour organiser les aspects de l’application réside dans l’utilisation des blocs applicatifs standards offerts par Microsoft. L’équipe Patterns et Practices a mis au point la 5ème version de la librairie destinée au développement des applications d’entreprise sous Windows : Enterprise Library. Ainsi, la couche métier et la couche d’accès à la base de données (les niveaux 2 et 3 de l’architecture 3 tiers) suivent solidement les bonnes pratiques de l’industrie pour que rien ne soit laissé sans surveillance. En outre, la « plomberie » de chaque application peut être développée de manière standard et appropriée, en utilisant les autres blocs :

• Le bloc de cache qui optimise le temps de réponse en gérant les données les plus souvent utilisées, pour diminuer les pics de trafic de la base de données
• Le bloc de cryptographie, qui gère efficacement le cryptage des informations sensibles
• Le bloc de journalisation qui aide les développeurs et les équipes IT lors des diagnostics
• Le bloc de validation, la manière commune pour créer et utiliser des règles de validation pour les objets métiers.

Il existe également des blocs, spécialisés pour les architectures et les scénarios professionnels : Unity for DI (Dependency Injection)/IoC (Inversion of Control), Policy Injection for AOP (Aspect Oriented Programming – implémentant des notions transverses – sécurité, cache, journalisation – dans toute l’application).
Ces blocs agissent comme des plugin : ils peuvent être configurés, remplacés, modifiés en fonction des scénarios métiers envisagés par le client et l’équipe de développement.

Conclusion

ASP.NET 4.0, conjointement à Visual Studio 2010 et au framework .NET 4.0 bénéficient des dernières versions, modernisées du groupe Modèles et Méthodes de Microsoft. En tirant parti de ces solutions, les équipes de développeurs seront sûres de suivre les meilleures pratiques de l’industrie lors du développement d’applications Web structurées, évolutives, et faciles à maintenir.

Beler Ingénierie : ne pas laisser de place au hasard.
Les développeurs de Beler essaient en permanence d’améliorer leurs connaissances autour des dernières technologies. C’est d’autant plus important que les architectures et les tendances s’empilent au gré des itérations des nombreuses technologies applicatives.

Diriger des projets de développement de logiciel consiste souvent à évaluer des risques.

Il n’est pas facile de planifier un projet et, en général, les équipes de développement rencontrent des retards à cause de certains aspects qu’elles ont oublié de prendre en compte pour diverses raisons. On peut dire que dans l’évaluation d’une tâche, on doit toujours intégrer le risque de difficultés imprévisibles : facteurs techniques, dialogue entre individus, etc… La plupart du temps une bonne idée consiste à opérer un transfert de risque, c’est-à-dire à éviter les aléas du développement, et donc supprimer autant que possible les nombreux facteurs qui peuvent aller de travers et causer des retards coûteux.

C’est ainsi qu’en cours de développement d’une application, les programmeurs et les responsables se retrouvent confrontés à ce choix : développer from scratch ou acheter des composants. Quelques aspects sont à prendre en compte lors d’une telle décision : l’expérience de l’équipe, la difficulté du problème technique, la connaissance du domaine fonctionnel, etc…

Actuellement, il y a plusieurs sociétés spécialisées dans la création de composants : DevExpress, Telerik, Infragistics, pour ne citer que celles dont j’ai déjà eu l’occasion d’expérimenter les produits. Leurs composants permettent de réaliser avec une énergie raisonnable des graphiques, des tableaux, des menus, des agendas, des barres d’outils, des listes, et tout un tas d’autres fonctionnalités qu’une application se doit de présenter.  Ces composants ciblent toutes les technologies Microsoft : ASP.NET, ASP.NET MVC, Windows Forms, WPF, Silverlight. DevExpress propose même des contrôles pour Delphi et C++ Builder.

Aussi le client s’attend-il à ce que toute demande spécifique sur l’interface utilisateur puisse être résolue soit avec les contrôles par défaut, soit avec un composant tiers. Et il est vrai que la plupart des commodités d’interface comme les vues de détail, les tris, l’auto-remplissage, les filtres, les changements de perspective, ont déjà été pris en charge dans plusieurs versions de contrôles.

Avantages :

• La phase d’apprentissage et plutôt légère puisque les développeurs accoutumés à travailler avec des contrôles standard comprennent rapidement comment utiliser des contrôles de tierce partie.
• On trouve des exemples de code pour chaque composant afin d’aider les utilisateurs à tirer bénéfice des produits le plus rapidement possible.
• Fréquentes mises à jour des bibliothèques.
• Plusieurs sociétés (en particulier DevExpress) sont renommées pour la qualité de leur support technique.
• Moyennant un coût supplémentaire, les développeurs peuvent disposer du code source, grâce auquel il est plus facile de résoudre rapidement un bug ou de modifier certains comportements sans les délais inhérents au support technique du fournisseur.

Avec un peu d’expérience, il devient vite évident qu’il vaut mieux fouiller dans les sites Web des fournisseurs de composants plutôt que tout développer de zéro. C’est assurément moins coûteux que documenter une analyse, développer, débugger, tester encore et encore. En utilisant des contrôles tiers, il est plus facile de se focaliser sur les fonctionnalités métier du projet, de passer du temps à développer les caractéristiques originales de l’application, plutôt que de travailler à résoudre les innombrables difficultés techniques sous-jacentes à chaque demande fonctionnelle.

En conclusion, si vous trouvez un contrôle tiers qui semble répondre à votre besoin, téléchargez la version de démonstration, testez-la, et réalisez un petit prototype pour le présenter au client. Si ça correspond à peu de choses prés à sa demande, ce sera à coup sûr meilleur marché de l’acquérir au lieu de développer vous-même la fonctionnalité.
D’un autre côté, si vous arrivez à la conclusion que le contrôle nécessite de sérieuses adaptations pour répondre au besoin, il vaut certainement mieux développer entièrement la fonction en s’appuyant éventuellement sur un simple contrôle par défaut du framework .NET.

La prochaine fois, j’approfondirai l’intêret du data grid de DevExpress.

Ca y est, votre entreprise veut créer son prochain produit pour navigateurs et vos développeurs vous affirment dans un premier temps «On devrait utiliser ASP.NET» pour vous asséner ensuite «non plutôt MVC». >

Sachant que les deux solutions sont des technologies .NET publiées non moins toutes les deux par Microsoft, c’en est à se demander si la question est légitime : est-ce qu’on ne devrait pas simplement utiliser celle dont on peut tirer le meilleur parti chaque fois que c’est possible ?

Pourquoi utiliser Web Forms ?

ASP.NET Web Forms est livré avec .NET, et pratiquement tout le monde l’appelle, à juste titre, ASP.NET.
Contrairement à l’ASP classique il est composé de contrôles, et il imite le développement Windows Forms. Avec tous ses avantages et ses inconvénients.

Vous pouvez concevoir votre application comme une application bureautique événementielle et dynamique, et vous le ferez rapidement en utilisant les contrôles existant ou en intégrant ceux des parties tierces.
ASP.NET est recommandé pour les applications professionnelles traitant des volumes important de données, car vous passerez l’essentiel de votre temps à coder en C# ou en VB.NET côté serveur, développement qui n’exige pas de peaufinage en Javascript.

ASP.NET Web Forms convient donc très bien, pour la migration d’applications bureautiques en mode saas.

Inconvénients : perte de contrôle et abstractions

La perte de contrôle sur l’affichage du code HTML a pour conséquence un support médiocre des standards à venir (par exemple, des balises dégradées en HTML 5 seraient toujours affichées par les contrôles existants), et l’existence de contrôles dans les pages peut rebuter certains concepteurs de sites web.

L’abstraction dynamique impliquant une baisse de performance (des volumes importants Viewstate transférés entre le client et le serveur à chaque clic), ces applications conviennent mieux aux développements Intranet. Si vous ne le souhaitez pas, il vous faudra travailler activement autour de Viewstate.

L’abstraction « événementielle » induit qu’il y a peu de chance de trouver, sur votre page web, des éléments à mettre en favoris (des éléments possédant leur propre URL), et si c’est le cas, l’URL peut ne pas fonctionner plus tard en cas de perte de son état dynamique.

Et ASP.NET MVC ?

ASP.NET MVC (Modèle Vue Controleur) n’est pas le premier framework pour ASP.NET [1] et il est la preuve qu’ASP.NET est une plate-forme très extensible. Il est cependant le seul qui soit intégralement supporté par Microsoft, intégré dans Visual Studio.

Model-View-Controller est le nom d’un modèle logiciel utilisé pour les développements d’interfaces graphiques, capable d’analyser très convenablement le modèle requête/réponse passif HTTP.

Pourquoi utiliser ASP.NET MVC ?

Les URL : Vous pouvez démarrer le site en concevant des URL optimisées pour les moteurs de recherche, sans extension et non liées à la manière dont vos fichiers sont stockés sur le serveur. Elles peuvent servir de signets, à moins que vous vous y opposiez de manière active.

Les Vues : Elles sont beaucoup plus faciles à concevoir car elles ne contiennent aucune référence à des contrôles (pas de balises cachées).

En même temps que les vues faciles à concevoir, vous pouvez choisir votre framework Javascript : Microsoft Ajax, jQuery ou tout autre framework maitrisé par vos développeurs. Vous avez les mains libres.

C’est pourquoi MVC parait être le meilleur choix pour les sites Internet grand public qui ne contiennent pas des formulaires importants à traiter avec des règles métier, ou qui ne demandent pas d’analyser, trier et filtrer des jeux de données.

Inconvénients : code à écrire et absence de contrôles

Pouvoir utiliser tout type de framework Javascript signifie qu’en fait aucun n’est intégré : il vous faudra écrire du code, ce qui vous prendra plus de temps.

Ne pas posséder de notion de « contrôles » signifie également qu’il vous faudra plus de temps pour développer une application événementielle. Dans ce cas, Web Forms est un meilleur choix.

Conclusion

Etudiez les deux, utilisez celui qui conviendra le mieux !

[1] http://www.castleproject.org/monorail/
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks

Désolé, cet article est seulement disponible en English.