Architecture des applications Aspectize

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.