| « Une journée extra-ordinaire | la Recette du Gâteau Logiciel selon Microsoft » |
la Modélisation Métier est elle soluble dans le CRUD (et inversement)?
http://docs.google.com/Doc?id=dhp3ggmx_115g524prcq
je vais lever une veille taupe, peut être un débat sans fin, mais il me parait important d'essayer de remettre les cartes sur table.
Plus les années avancent, et plus je me questionne sur où vont les technologies et les éditeurs ou les projets Open Source?
Et je me demande si on ne frôle parfois pas la schizophrénie...
Par exemple chez Microsoft, on nous dit : "CRUD, Only When You Can Afford It" ( http://msdn.microsoft.com/en-us/library/ms978509.aspx )
et après on met en avant ASP.NET Dynamic Data, qui permet de faire des applications 100% orientées CRUD.
Au début était l'informatique, les carte perforées, puis les disques durs. Et tout cela stockait des données, des données, des données.
Puis vint Merise en grand éclaireur de la pensée informatique industrielle (pendant que les scientifiques n'en avaient cure, et persistait dans une voie fonctionnelle).
Ce que faisaient alors les logiciels se résumait en 4 verbes: Créer, Lire, Modifier, Effacer des données (Create Read Update Delete, CRUD en anglais).
Et après de nombreux logiciels produits sur ce modèle, on s'est rendu compte que:
1) cela ne faisait que produire des logiciels d'informaticiens, c'est à dire pas du tout "User Friendly";
2) la complexité de la réalité dépasse le stade de ces 4 opérations basiques.
On a commencé à réfléchir du point de vue de l'utilisateur. On s'est aperçu qu'il avait un besoin de logiciel dans le but de l'assister dans l'exécution de son métier (et accessoirement que l'utilisateur était livré avec des yeux).
On a donc sorti une artillerie lourde pour décrire - MODELISER - les processus métier, issus du besoin réel de l'utilisateur, représentés bien souvent par des Scénarios Utilisateurs (merci UML).
Des paradigmes tels que le "Model Driven Design" ou le "Domain Driven Design" sont venus consolider cette nouvelle façon de faire du logiciel.
Pourtant le CRUD n'avait pas pour autant disparu...
On a l'habitude de dire qu'il ne faut pas exposer les données directement au dessus d'une couche métier, tels que ce que l'on peut trouver exposé par un Web Service, et pourtant nombre d'applications le font.
et Microsoft qui va droit dedans avec SdS et ASP.NET Dynamic Data.
"Data-driven application" redevient un mot que l'on peut prononcer sans honte.
Microsoft n'est pas le seul, avec la lame de fond qu'est REST, tout est orienté ressource, donc données, et les opérations permises sont encore au nombre de... 4!
Question légitime: comment exprimer du métier avec ce genre d'outils?
Comment faire dans cet incessant aller-retour entre une paroisse et une autre? Est-ce un éternel recommencement? (et piétinement?)
la suite sur http://docs.google.com/Doc?id=dhp3ggmx_115g524prcq
3 commentaires
Je voudrai juste faire quelques remarques basiques. Je pense que le CRUD quoi qu'on en dise a encore de beaux jours devant lui, quoi qu'on fasse, il y aura toujours besoin de ces opérations simples. Aujourd'hui on ne perfore plus de cartes et on évite de programmer en assembleur grace à des langages de haut niveau, mais l'ordinateur ne comprend toujours que du binaire. C'est un peu pareil avec CRUD, quel que soit le niveau d'exposition dont ait besoin le métier il y en aura toujours besoin.
Pour rebondir sur Asp.Net Dynamic Data, c'est comme pour Asp.Net MVC, il ne s'agit pas d'un retour en arrière mais juste d'une solution pour répondre à une catégorie de problèmes. Suivant le degré de complexité de votre métier, le temps imparti, le niveau de sécurité,etc,..., vous serez amenés à utiliser dans le futur des webforms, du Dynamic Data ou du MVC.
So...j'attends maintenant avec impatience que tu nous fasses un bel article sur M par la pratique ;-)
Mais ce n'est pas vraiment le fond exact de ma pensée.
Je pense comme toi qu'il y a des projets (ou des couches du projet comme l'UI) où le CRUD va bien nous rendre service, et nous permettre d'aller vite.
C'est juste qu'il faut dire: attention à ne pas aller trop vite.
Et également, quand on est sur un plus gros projet, avec plus de moyens, on est toujours tenté de faire du CRUD, et je donne quelques idées pour ne pas tomber dedans tête baissée.
Merci pour ce commentaire en tous cas.
Peut-être que le problème, c'est qu'on veut toujours trouver LE modèle, L'ARCHITECTURE qui correspond au poil à nos besoins... sans forcément avoir définis ces dits besoins au préalable.
Flux de commentaires pour cet article