MVC : L’immacul?? (Motif de) Conception

Un monde presque parfait

Vous êtes prêts à entendre une terrible révélation ?

Le développement de réelles applications Flex ne se passe pas tout à fait comme dans les exemples fournis par Adobe. L’éminent formateur Yann Chevalier nomme ce phénomène désagréable le passage à « la vraie vie« .

Or donc, dans la vraie vie que se produit-il ?

Souvent, on commence comme on l’a appris en formation, lu dans des bouquins et vu sur des exemples : MXML, balises <fx:Script> et code de gestion des événements. Ça marche au début, puis au fur et à mesure des ajouts, ça devient un peu complexe à gérer, puis franchement compliqué à maintenir, et enfin carrément l’angoisse à chaque mise à jour.

4116825468_a4ab62ae8d_m

Hum..du code spaghetti !

(http://www.flickr.com/photos/jbozanowski/with/4116825468/)

Depuis les origines de Flex, les experts tentent d’apporter une solution ultime à ce problème entropique en vulgarisant l’emploi de Design Patterns ou Motifs de Conceptions.

Pour faire simple, il faut apprendre à structurer ses développements. Plutôt que de réinventer le fil à ouvrir les huîtres (oui par chez moi en Bretagne c’est pas l’eau tiède, allez savoir pourquoi), autant ré-utiliser les bonnes pratiques déjà éprouvées, identifiées et répertoriées. Ces bonnes pratiques proviennent essentiellement de la communauté Java et par capillarité se transmettent à la communauté Flex.

Un des grands principes fondateurs, (Programmation Objet, architecture en couches), consiste dans la séparation des problèmes : Separation of Concerns :

« Layered designs in information systems are also often based on separation of concerns (e.g., presentation layer, business logic layer, data access layer, database layer).« 

Certaines initiatives vont plus loin encore et proposent directement des frameworks qui garantissent le respect des bonnes pratiques au travers de la mise en oeuvre des Design Patterns. Cet article va présenter ces différentes notions, tout en listant plusieurs ressources couvrant le spectre allant de la théorie vers la pratique.

Les Design Patterns : la théorie

Beaucoup d’autres ont écrit sur ce thème, mais la référence dans le domaine se nomme Martin Fowler. Sur son site et dans ses livres, vous pourrez décortiquer à loisir toutes les subtilités des différentes architectures applicatives. 

Martin_fowler_qcon_2007

Laissez de côté pour l’instant ce qui touche à l’Agilité et au refactoring. C’est passionnant, Martin Fowler constituant une référence également sur ces sujets, mais sinon on ne vous revoit pas avant plusieurs mois !

Le livre qui se rapporte au thème de cert article se nomme Patterns of Enterprise Application Architecture. Les exemples y sont donnés pour Java et C++. :

Eaa-sm

Si vous voulez quelque chose de directement applicable à Flex, reportez-vous aux ouvrages suivants  :

Actionscript3

As3-designpatterns

Les Design Patterns : l’application

Si vous êtes un peu pressés ou rebutés par le format papier, plusieurs bloggeurs ont oeuvré pour proposer des tutoriaux d’introduction aux principaux Design Patterns utilisés pour structurer une application Flex. Je vais lister ci-dessous quelques-uns de ces articles concernant l’architecture Model-View-Controller (MVC).

L’industrie informatique n’a pas attendu Flex pour se préoccuper d’architecture logicielle puisque le concept de séparation des couches en MVC remonte à la fin des années 70. Pour les mordus d’histoire, se référer à Wikipedia.

« Model-View-Controller (MVC) is a software architectural pattern where an application is broken into separate layers for the data model, the user interface (view), and the business logic. The logic, model, and views are decoupled, and communicate through an intermediary controller. This pattern enables both abstraction of logic, and reuse of code/components throughout the application.« 

Bon article d’introduction qui a, en particulier, le grand mérite d’exposer clairement que dans le domaine des RIA, on parle de MVC sur le client indépendamment de l’architecture MVC du serveur.

Voici un schéma qui tente de résumer cette notion de MVC Server :

Mvc-server-500

  • David Deraedt aborde également ce concept dans une série de quatre articles sur Flex Architecture Fundamentals, en particulier dans l’épisode 3 : Designing the Flex application as a Model View Controller.
  • Bogdan Serban a posté sur Adobe Developer Connection / Cookbooks / AIR, Flex, un très bon article Simple MVC for Flex and AIR. Il y fait preuve d’un respectable pragmatisme :

« In reality there is no 100% demarcation between these three layers. Is not that easy to make them completely decoupled and usually we end up making some tradeoffs.« 

et met en application le modèle sur la réalisation de l’ajout de valeurs à une liste :

Image-list

Voici un autre schéma décrivant l’architecture retenue par l’auteur dans son exemple :

Mvc-simple500

A noter que le Modèle est un singleton.

<controllers:SampleController id= »controller » view= »{this} »/>

Autre caractéristique forte de cette variante : « the view NEVER directly accesses the model. » Principe qui appliqué dans la « vraie vie » peut amener à des conséquences assez importantes sur ce que le controleur doit ré-exposer comme données du modèle. D’autres auteurs préfèrent appliquer directement la directive [Bindable] sur les variables publiques du modèle ce qui, implicitement, entraîne l’émission d’événements en cas de modification.

Cet exemple soulève une autre interrogation importante :

« Some people will argue that the httpservice should be in the model rather than in the controller.

Pas si simple de ranger ses affaires !

Vous pouvez trouver une traduction en français sur le blog de Fabien Nicollet : www.flex-tutorial.fr.

  • L’approche MVCS, décrite par Joe Berkovitz sur son blog et dans une conférence présentée à Max 2006, répond à cette problématique en accolant au MVC la notion de couche Services, responsable de la communication avec l’extérieur :

« Encapsulates all communication with the outside world. Populates Model objects with remote data »

Encore un expert qui prône le pragmatisme lors de l’application des modèles à la vraie vie :

« Since the original MVCS article I have since built a number of ambitious applications. In each one of them I felt it necessary to substantially modify the plain MVCS approach in order to preserve my notions of “right development practice”. « 

Universelleu panacée-éhé ?

(http://www.dailymotion.com/video/x22ung_le-sirop-typhon-richard-anthony_music)

Mon retour d’expérience sur ce sujet :

  • Tout développeur qui passe plus de quelques jours sur Flex ressent rapidement la nécessité de choisir une architecture pour son codage ou de se renseigner sur la hauteur des ponts environnants.

Ambresin

(commons.wikimedia.org/ wiki/File:Ambresin.jpg)

  • MVC est reconnu comme un Design Pattern de base, jusque là tout va bien. 

– Ah mais non, MVC c’est pas suffisant, regarde MVCS.

– Pas du tout, il FAUT adopter Presentation Model, …

  • Dès que l’on creuse un peu le sujet, on s’aperçoit que chacun a sa propre compréhension du motif de conception MVC. 

– La vue référence-t-elle le contrôleur ?

– MVC passif, actif ?

– …

  • Quand l’heure vient d’appliquer à son propre développement ce qu’on pense avoir compris, on se sent généralement envahi d’une terrible indécision : 

– passe-t-on par des événements ou des membres publics ?

– Où range-t-on nos services, contrôleur ou modèle ?

– Comment expose-t-on le modèle à la vue ?

– Où écrit-on la logique métier ?

– Est-ce que je ne suis pas en train de mettre en place un « machin » complètement surdimensionné ?…

    Ça vous évoque quelque chose ?

    Architecture propre ou frameworks ?

    Si vous êtes convaincus par la nécessité d’organiser votre code, demeure cependant le choix de la démarche :

    • définir vos propres conventions (au prix d’interrogations existentielles, se référer au paragraphe précédent),

    ou

    • adopter un framework prêt à l’emploi.

    Comme base de réflexion sur la définition de vos propres conventions, je vous recommande la lecture de deux articles de Fabien Nicollet. Fabien y présente son retour d’expérience sur le développement pour mobiles et explique l’architecture qu’il a retenu pour une réutilisation de composants :

    Si vous préférez la démarche éprouvée d’un framework existant, il vous reste à effectuer votre choix parmi les nombreuses propositions existant dans le communauté Flex. Généralement l’expérience préalable, le contexte de l’entreprise et le type d’applications à réaliser sont déterminants. Suivant que l’on vienne du monde Java ou PHP, la culture jouera un rôle important dans l’adoption du framework.

    La plupart des frameworks Flex mettent en oeuvre les principes du MVC. Voici quelques liens absolument non exhaustifs :

    Aller plus loin

    Le net regorge d’articles sur la question. Vous trouverez en particulier nombre d’articles intéressants sur http://www.developria.com/.

    N’hésitez pas en particulier à poster en commentaire des liens vers vos propres conventions d’architecture. Je pense que le sujet est loin d’être épuisé !

    Laisser un commentaire

    Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

    Logo WordPress.com

    Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

    Image Twitter

    Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

    Photo Facebook

    Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

    Photo Google+

    Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

    Connexion à %s

    %d blogueurs aiment cette page :