Aspectize MSV = MVC + SOA + ORM + ESB

Lors de notre élaboration de notre marketing stratégique, une question importante se pose sur notre catégorie; dans quelle catégorie voulons nous apparaître ?

La catégorie est essentielle parce qu'elle permet rapidement à nos interlocuteurs de nous positionner, et d'évaluer notre proposition de valeurs relativement aux autres outils de la même catégorie. Et c'est une question difficile, parce que notre approche est suffisamment différente pour que l'appartenance à l'une d'elle ne saute pas forcément aux yeux.

Aujourd'***, il nous est plus facile de dire dans quelle catégorie nous ne sommes pas. Par exemple, nous nous démarquons fortement des principales catégories des outils de développements:

• les Frameworks, qui proposent des API et pour lesquels il est nécessaire d'écrire du code pour les utiliser. Nous n'avons pas d'API (hormis le chargement des données qui nécessitent aujourd'*** d'écrire du code), et nous encourageons à écrire le moins possible de code. Nous réduisons significativement les API .Net à connaître pour développer une Application.
• les Générateurs de Code, qui proposent des outils de modélisation, mais dont la sortie est un code à intégrer dans une solution, complété par du code métier et compiler pour donner l'application finale. De ce point de vue, nous sommes plutôt un éliminateur de code.
• les AGL, qui propose des boites noires souvent fermées de plus haut niveau qui permettent de développer vite, mais qui vieillissent mal et s'intègrent mal avec l'existant. Nous sommes complètement intégrés à l'environnement .Net.
  
  

Si l'on se place du point de vue des briques qui constituent une Architecture d'Entreprise, on peut considérer les catégories suivantes, qui représentent à peu près les règles de l'art en la matière:

• les ORM, qui s'apparentent à des Framework ou des générateurs de code pour faciliter l'accès au stockage des données.
• les ESB, qui sont plutôt des middlewares, qui facilitent la mise en œuvre d'une SOA.
• les Framework MVC, qui sont le modèle le plus répandu pour réaliser l'IHM des applications.
  
  

Chacune de ces briques adressent bien des fonctionnalités de l'architecture, que nous adressons également, nous sommes donc un peu tout cela à la fois...

Et pourtant, quand on regarde comment Microsoft nous invite à réaliser ces différentes briques, on s'aperçoit qu'elles nécessitent beaucoup de code pour être implémentées. Cela vient principalement de l'approche orientée objet et du typage fort utilisé à tous les niveaux.

Notre vraie différence est d'avoir choisi une autre approche, ce qui nous permet d'éliminer l'essentiel du code à écrire, avec une séparation bien plus nette entre les différents éléments (vu qu'il n'y a plus de code pour les lier). Nous avons permis d'unifier toutes les briques de l'Architecture et de faire tout-en-un, beaucoup plus facilement.

Notre Modèle relationnel permet de définir les fonctions de mapping avec le stockage, ce qui offre les bénéfices d'un ORM, sans les inconvénients du mismatch entre le monde objet et relationnel. Meilleur mapping (pas de soucis pour les relations N-N par exemple), requêtage beaucoup plus facile (extraction de graphes et lazy loading trivial), support du n-tiers.

Nos Vues sont bindées dynamiquement sur le Modèle, ce qui correspond bien à la logique du MVC. Notre moteur de binding est en quelque sorte le C, le contrôleur universel, qu'il n'est pas nécessaire d'écrire, et avec lequel une logique déclarative suffit. Les vues sont des contrôles purs, il n'y aucun éléments du modèle qui intervient pour définir la vue, la définition du binding est externe à la vue. Cela permet une séparation définitive entre la présentation, au sens ergonomie et design, et le Modèle.

Notons au passage que le Modèle est bien le même que celui qui est utilisé pour le mapping avec le stockage et pour le binding avec les Vues. Et comme le binding est réalisé sur le client, vous disposez d'une Application Ajax native, et vous limitez les allers et retours avec le serveur à des échanges de données uniquement.

Nos Services sont découverts et appelés dynamiquement dans un contexte complètement distribué ce qui correspond bien aux fonctionnalités d'un ESB dans le monde .Net. Vu que l'ensemble du code est dans des Services, qui sont directement drivés par les besoins métiers, l'architecture SOA est naturellement réalisée sans avoir à écrire le moindre code technique.

Finalement, il reste bien un triptyque Modèle/Service/Vue, qui suffit à bénéficier de toutes les fonctionnalités d'une Architecture d'Entreprise: MVC, SOA, ORM et ESB.

Alors, est ce que la catégorie MSV reste à inventer ?