Les news d'Aspectize

DataBinding et CommandBinding

Nico — Tue, 20 May 2008 07:15:00 GMT

Le DataBinding est l’art de connecter de façon bi-directionnelle des contrôles à leur source de données. C'est une solution pour éviter d'écrire du code fastidieux de mise à jour de données entre une des propriétés des controles de l'IHM et des données métiers. Microsoft a apporté cette fonctionnalité avec le framework 2.0, et c'est une technique éprouvée, pour réaliser des IHM de façon efficace.

Pourtant, il y a quelques limitations, qui font que cette technique est assez peu utilisée:

Tous les contrôles ne sont pas concernés; si on peut binder tous les contrôles simples, et les liste ou les grilles, il manque les arbres, les listview ou les Menus.
Le Designer de Visual Studio n'invite pas à l'utiliser. Personnellement, je n'ai jamais pu définir correctement un DataBinding avec leur interface, même avec un tutorial bien fait.
Le DataBinding n'est pas immédiat non plus à faire avec du code. Il est nécessaire d'écrire beaucoup de code, en implémentant des Interfaces diverses, qu'il faut bien comprendre pour le faire correctement.

Avec Aspectize, le DataBinding que nous proposons est particulièrement enrichi et devient très facile à utiliser:

Toutes les propriétés de tous les contrôles sont bindables. En particulier les arbres, pour lesquels cela relève presque de la magie, tant il est facile de réaliser un arbre complexe, de façon déclarative. Cela permet aussi de binder des propriétés habituellement dédiée à la présentation, comme un BackColor ou un Enabled (exemple courant d'une BackColor Red pour un montant négatif). Cela permet de réaliser des interfaces riches sans écrire une seule ligne de code.
Le DataBinding est déclaratif; il n'y a pas une seule ligne de code à écrire. Il se définit en quelques clics de souris avec BindingStudio, qui porte bien son nom.
Toutes les conversions de données standard sont prises en charge automatiquement. Si votre donnée est un numérique, vous n'avez rien à faire pour la binder dans un TextBox. Les formats standards sont pris en charge, notamment pour les dates et les numériques.
Le DataBinding prend en charge les relations entre les données. Réaliser des contrôles Parent/Child fonctionne avec tous les contrôles. C'est particulièrement efficace pour les arbres, dont les noeuds sont des liens Parent/Child entre des données, mais aussi pour des applications MDI (la relation MDI/MDIChild s'appuie sur une relation entre des données), des TabControl (les TabPages sont les Child d'une donnée commune parent) ou encore les ComboBox (qui permet de modifier des associations entre 2 entités).
Il est enrichi aux Commandes. De la même manière que les propriétés reflètent des données, les événements sont associés aux commandes. Là encore, pas une seule ligne de code n'est nécessaire, et BindingStudio vous permet en 2 clics de souris, d'associer une commande Server à un clic de bouton. Nous parlons alors de CommandBinding.

Le DataBinding est une technique très intéressante pour éliminer du code, mais néanmoins un peu difficile à utiliser, et qui reste limitée. En l'étendant et en la généralisant, nous la rendons accessible à tous, pour l'ensemble des IHM. Nous l'avons déjà fait pour les interfaces WinForms, nous sommes en train de le faire pour Asp.Net/Ajax, et nous la porterons vers WPF et SilverLight dans un avenir proche.

Nous verrons également, comment associer une validation de données, qui devient, elle aussi, déclarative.

Entity Designer pour VS 2008

Nico — Tue, 06 May 2008 07:21:00 GMT

Pour être tout à fait complet sur l'intégration à Visual Studio, il manquait encore la version d'Entity Designer pour VS 2008.

C'est désormais chose faite, elle est disponible dans la version d'évaluation, en téléchargement.

Architecture des applications Aspectize

Nico — Mon, 28 Apr 2008 18:44:00 GMT

L'Architecture d'une application Aspectize peut se présenter ainsi:

Elle est composée de 2 Applications logiques distinctes :

- l'Application Server, qui a pour fonction :

la lecture/écriture des données dans une ou plusieurs bases (SQL Server 2000/2005, Oracle 10) ou fichiers XML
les calculs métiers complexes

- l'Application Client, qui a pour fonction :

l'affichage des données dans les contrôles de l'IHM
la validation des données

L'ensemble des éléments de l'application sont dans des Dll:

le Schéma de l'application, réalisé avec Aspectize Entity Designer (DSL de Visual Studio). Il permet de définir graphiquement le modèle Entités/Relations de l'application, avec des attributs haut niveaux, comme la validation, le calcul de données, la temporalité ou la multiplicité, ainsi que des événements logiques sur la modification de données,
les contrôles de l'IHM, réalisés avec le designer de Visual Studio, sans écriture de code. Tous les contrôles standards de Microsoft sont supportés.
le code métier, écrit dans des Commandes .Net standards, en privilégiant le comportement métier et en excluant tout code technique (SQL, traitement d'erreurs, log/trace, distribution, fail over, sécurité, intercepteurs pour l'application serveur, data-binding, conversion de données, drag & drop, appels serveurs, bouchons pour l'application client)

Les liens entre ces différents éléments sont déclaratifs et sont faits en quelques clics dans Aspectize Binding Studio:

Configuration du Data Binding relationnel des Contrôles sur les Entités du Schéma

une propriété d'un contrôle est associé à une Entité du Schéma
le Validateur de données est configuré pour afficher l'erreur et/ou empêcher le contrôle de mettre à jour la donnée

Configuration du Command Binding des Contrôles sur les Commandes Métiers

un événement d'un contrôle est associé à une Commande client ou serveur
les paramètres d'appels sont bindés sur les Entités du Schémas, ou les autres propriétés des contrôles, ou encode le profil utilisateur

Configuration des Services

accès aux données (ConnectionString ou FileName)
sécurité/trace/log de l'application
intercepteurs

Aucune référence n'est nécessaire entre les autres composants de l'application, à l'exception des Dll du schéma qui sont référencées dans le code métier, car celui-ci manipule les entités du schéma. Aucune référence à un quelconque élément physique (serveur, stockage, contrôles physiques) n'est utilisée dans l'écriture de code.

Aucun code n'est nécessaire dans les contrôles de l'IHM. Les contrôles ne sont pas liés ni aux données, ni aux traitements.

Il en résulte une souplesse et un gain de productivité tout à fait remarquable. Nous verrons, étape par étape, comment mettre en oeuvre l'application exemple sur la base AdventureWorks, et obtenir une application riche et complexe en quelques minutes de travail.

Aspectize en Images

Nico — Mon, 03 Mar 2008 19:54:00 GMT

A l'occasion des TechDays, Microsoft nous a proposé de réaliser un petit film de démonstration de nos produits.

Exercice toujours difficile et intéressant, voici donc une vidéo de 4'30 pour présenter rapidement notre plate-forme de développement.

Un grand merci à Microsoft et à l'équipe de Brainsonic qui a réalisé le film.

Version disponible en téléchargement

Nico — Fri, 22 Feb 2008 19:45:00 GMT

Nous mettons à disposition une version d'évaluation, qui vous permettra d'installer et de démarrer avec notre produit.

Elle est accompagnée de tutoriaux qui permettent de réaliser une petite application exemple en Visual Studio 2005. L'application à réaliser est une petite application WinForm client/serveur qui permet de naviguer dans l'arborescence des produits AdventureWorks, et d'afficher le détail d'un produit. La base de données est livrée avec les tutoriaux, et est à importer dans SQL Server 2000 ou 2005 (le modèle a été légèrement retouché pour plus de souplesse !).

Cette application contient en tout 7 lignes de code et est réalisée en quelques minutes. Elle vous montrera la puissance de notre plate-forme et vous permettra de mesurer les bénéfices de la nouvelle approche que nous préconisons pour le développement d'applications métiers, à savoir:

gagner du temps en éliminant tout le code technique, qui n'est pas à écrire, et qui n'est pas non plus généré.
diminuer les risques en ne faisant plus de choix techniques structurants. Vous développez d'abord, vous architecturez ensuite.
valoriser votre métier, en livrant vos applications dès le premier jour, et en faisant participer vos utilisateurs au plus tôt dans le cycle de développement.
pérenniser vos développements fonctionnels, en les réutilisant dans des architectures physiques variées.

D'autres tutoriaux et démonstrations sont à venir, qui permettront d'aller encore plus loin et de réaliser des IHM complexes, des architectures distribuées, des applications sécurisées, et ceci en n'écrivant uniquement le code métier.

Ce n'est pas écrit dans le cahier des charges

Nico — Tue, 04 Dec 2007 21:22:00 GMT

Rapide sondage autour de moi. Pratiquement tous les développeurs ont un jour été confronté à cette situation.

Le client exprime, ou fait exprimer par un tiers, son besoin dans un document qu'il est convenu d'appeler un cahier des charges. Un prestataire s'engage à réaliser l'application selon le contenu du document. Un accord est trouvé entre le prestataire et le client sur les modalités de fonctionnement (livrables, coût et délais). Cette démarche est aujourd'*** la plus générale, que le prestataire soit interne ou externe n'y change rien d'ailleurs.

Nous nous étonnions de la similitude avec le métier du bâtiment où Maîtrise d'oeuvre et Maîtrise d'ouvrage sont les mêmes termes utilisés pour désigner les 2 parties. Comment font d'ailleurs les professionnels de l'immobilier pour exprimer le besoin ? Ils font des plans, des dessins et des maquettes. Il est facile pour un client final de visualiser, d'imaginer ce que sera son appartement à partir d'un plan. La taille de la salle de bain, le couloir, l'emplacement de la fenêtre sont des éléments à sa disposition très tôt, et qui ne bougeront plus. Là s'arrête l'analogie avec le Système d'Informations. Car, si l'usage de maquettes permet à l'utilisateur de visualiser son application, celle-ci a des limites. D'abord, il est rare de faire une maquette exhaustive selon les besoins. Quand elle est faite - elle a un coût de réalisation non négligeable dont les prestataires essaient souvent de faire l'économie - elle est superficielle. D'autre part, le besoin sera de toute façon complété par l'usage. L'utilisateur est pragmatique, rien ne vaut l'expérience utilisateur pour améliorer et enrichir une application.

Et quand arrive le moment où les premiers éléments sont entre les mains du client, c'est assez systématique. Il y a toujours un truc, plus ou moins important, une fonctionnalité qui ne correspond pas exactement aux attentes du client. Et si le besoin mal ou pas exprimé est structurant, la correction est probablement douloureuse pour celui qui réalise.

L'approche que nous proposons avec Aspectize permet de réaliser les applications au fur et à mesure des besoins. Dès le premier jour, le client peut avoir une application qui est dans un état fini. Elle n'est pas terminée, mais elle fonctionne, et il peut tout de suite savoir si ce qui a été fait correspond à son besoin. D'abord, les développements sont vite faits, mais les modifications sont faciles, parce que les pièces sont découplées. Ajouter ou enlever un champ à une entité, ne casse pas l'existant. Modifier l'organisation d'un arbre se fait en quelques clics de souris. Sauvegarder des données en base, s'écrit en une ligne de code. Le besoin peut donc être implémenté au fur et à mesure de son évolution. Et l'architecture suit, parce que les éléments sont complètement indépendants les uns des autres. Le couplage quasi nul entre les différentes briques permet leur réorganisation et leur réutilisation. Il est facile de réorganiser un chargement de données, de déplacer un traitement sur un serveur, d'ajouter de la sécurité à une application.

C'est ce que nous tenterons de montrer lors de nos démonstrations. Soyons pragmatique.

Système d'Information Dynamique

Nico — Mon, 12 Nov 2007 09:41:00 GMT

Un Système d'Information Dynamique est un Système d'Information vivant qui évolue constamment en fonction des besoins de ses utilisateurs.

Il est souple, parce que les évolutions demandées sont réalisable facilement et rapidement et parce qu'elles ne cassent pas l'existant. Vision utopique ? Peut-on ajouter facilement des fonctionnalités nouvelles sans casser du code qui fonctionne ?

La première idée qui vient quand on se pose cette question, est la réponse d'une "bonne architecture". Une bonne architecture permettra la définition des différentes briques du Système d'Informations, de façon à permettre leur évolution de façon indépendante. Le SI peut évoluer de façon incrémentale, par ajout successif de différentes briques. Chaque brique est indépendante des autres, elle vit sa vie propre au sein du système. C'est pourtant la cohérence de l'ensemble qui donnera toute la valeur du système et permettra aux fonctionnel d'être implémenté. Pour ce faire, il y a des liens entre les briques, elles se connaissent les unes des autres, elles se parlent, elles échanges des informations. Elles doivent se mettre d'accord sur la façon d'échanger de l'information, et sur la nature de l'information échangée. La bonne architecture répondra à ces questions.

2 remarques cependant:

la définition d'une bonne architecture et sa mise en oeuvre prennent du temps. Les bonnes pratiques et les outils sont là pour réduire ce temps, mais il est difficilement réduit à zero.
les liens qui seront mis en oeuvre entre les différentes briques du système, seront des liens qui apparaitront dans le code. Qu'il s'agisse d'un appel à un service, d'une référence à un objet, ces liens se traduisent par des opérations impératives, qui nécessitent d'être intégrées dans le processus de développement. Même en respectant la "bonne architecture", le couplage entre les différentes briques a toutes les chances d'être présent dans le code.

Le couplage faible visera à réduire les liens entre les différentes briques. Moins il y a de liens, mieux c'est.

Imaginez que vous pouvez maintenant développer vos différentes briques, sans vous soucier des autres, ni des liens que vous aurez à créer avec les autres. Vou souhaitez une IHM qui représente une information particulière. Seul vous importe la présentation de cette information. Le lien avec le contenu ne devrait pas être l'objet de votre développement. Vous souhaitez développer un service qui réaliser un traitement particulier. Seul vous importe le traitement que vous souhaitez apporter à votre information. L'endroit où se trouve l'information, la façon dont elle est stockée ne doit pas être l'objet de votre développement.

Vous concentrez votre travail sur le métier, la présentation et le traitement. Vous vous occuperez plus tard des liens à faire entre ces briques. Vous ne ferez pas de code pour implémenter ces liens. Pas de Event Handler sur un bouton, pas de propriétés d'objets à introduire dans un contrôle. Non seulement vous n'écrirez pas ce code, mais personne d'autre ne le fera non plus, ni une autre personne, ni un générateur. En fait, il n'y aura pas de code pour décrire ces liens. Ces liens deviennent descriptifs, ils sont de l'information dynamique, qui peut très bien se décrire sans passer par de l'écriture de code.

Les avantages sont considérables:

cela prend moins de temps à faire
cela peut se faire plus tard
cela est plus facilement maintenable, dans le sens où il y a moins de contrainte sur des éléments descriptifs que sur des élément impératifs (typage, ordre, référence)

Cela permet surtout la totale indépendance entre les briques, qui peuvent vivre leur vie de façon indépendante, puisqu'il n'y a plus de liens à faire avec l'existant. Si vous ajoutez un traitement ou un contrôle, vous n'avez que l'implémentation du traitement à inclure dans votre code, que votre contrôle à ajouter dans votre page. Vous exprimerez plus tard que votre bouton appelle votre nouveau traitement. Vous n'avez plus besoin que votre traitement soit fait avant votre bouton. De fait, votre bouton ne connait même pas votre traitement, et il ne le connaitra jamais.

Imaginez maintenant que l'infrastructure qui vous permette de travailler de cette façon existe. Seriez-vous impatient de la voir et de la tester ?

Bienvenue sur le blog d'Aspectize

Nico — Wed, 31 Oct 2007 16:36:00 GMT

Ce blog est destiné à communiquer et échanger sur la société et ses produits. Fil d'actualité de la société, il est destiné à faire partager nos idées et communiquer sur notre activité.

Il y sera donc question de développement et de méthodologie, de systèmes d'information, de Microsoft .Net, et surtout de souplesse et d'agilité, puisque c'est l'approche que nous souhaitons proposer avec nos produits.

Nous avons lancé notre aventure il y a maintenant presque un an. De la page blanche, les idées ont émergé, elles se sont mises en place naturellement, à notre rythme, pour aboutir à une démarche réellement innovante dans le domaine du développement de systèmes d'informations .Net et les outils qui permettent de la mettre en oeuvre. Aujourd'*** est venu le temps de communiquer, d'expliquer et de montrer ce que nous sommes en train de réaliser.

Nous aurons l'occasion de dévoiler ici les atouts de nos produits et de notre démarche, et d'échanger avec vous sur leur potentiel et vos retours d'expérience.