Fidèle à la politesse légendaire des outils de développement, nous commençons donc par une sorte de "Bonjour Monde !" (ça sonne bizarre en français...) transformé dans notre cas en "Au revoir Monde !" car c'est un nouvel univers que nous prenons en main avec Salamanca.

Voici venue l'heure de faire un tour de chauffe et de voir comment se comporte notre embarcation à travers un prototype de notre application web développée suivant 2 approches :

  • un formulaire ASP.NET
  • une question dans une activité Salamanca
Dans l'application web métier qui sert de fil conducteur à ce carnet de bord, l'utilisateur va principalement manipuler des projets. L'activité initiale à l'origine de l'ensemble du processus a été spécifiée sous la forme suivante :

En tant que donneur d'ordre, je veux pouvoir soumettre un projet en ligne afin de décrire un besoin métier en un minimum de temps.

Formulaire ASP.NET

ASP.NET FormView Un formulaire web peut être rapidement assemblé dans Visual Studio à partir d'une table dans une base de données SQL Express et des contrôles ASP.NET FormView, SqlDataSource. 

CREATE TABLE Projets(
	Id int IDENTITY(1,1) NOT NULL,
	Titre nvarchar(255) NOT NULL,
	Description ntext NOT NULL,
	...
)
<asp:FormView ID="_FormView" runat="server" DataKeyNames="Id" DataSourceID="_SqlDataSource"> ...
</asp:FormView>
<asp:SqlDataSource ID="_SqlDataSource" runat="server"  ConnectionString="<%$ ConnectionStrings:Proto %>" > ... 
</asp:Sqldatasource>

Grâce à l'environnement et aux outils mis à notre disposition par Microsoft, nous pouvons donc aller très vite pour "assembler" un écran qui pourrait satisfaire l'exigence métier. Par contre, pour satisfaire nos attentes et disposer d'une application robuste, modulaire et maintenable, c'est moins certain... Par exemple, maintenir toutes les requêtes SQL inclues directement dans la page web s'avère rapidement consommateur d'énergie lorsqu'on fera évoluer le modèle de données.

Question Salamanca

Ce que nous avons retenu de l'usine à logiciels Salamanca, c'est l'introduction du concept d'activité métier pour répondre à la problématique de séparation entre les 3 couches : Présentation - Métier - Accès aux données. Une activité s'exécute à partir de données définies dans un modéle objet et interagit avec l'utilisateur à travers des questions auxquelles sont associées des écrans.

Nous avons ainsi conçu le modèle d'activité suivant pour satisfaire l'exigence spécifiée :

Activité Soumettre un Projet

Dans le diagramme de notre activité ci-dessus, nous avons :

  • un état qui pose une question à l'utilisateur : AskProjetInfos
  • deux états de traitement : CreateProjet, SaveProjet
  • un conteneur des données manipulées : Data

Nous verrons lors d'une prochaine escale comment les entités métier constituant les données de l'activité sont modélisées et le code des classes comme des tables associées sont générées.

Notre but ici est de faire le parallèle avec le prototype de formulaire ASP.NET, donc d'introduire comment est implémentée la présentation du même écran.

Lors son exécution, l'activité fournit la référence au projet créé dans la question invitant l'utilisateur à saisir les informations de description de son nouveau projet. On peut alors directement lier l'interface homme-machine avec l'instance de l'entité métier chargée de la persistence des informations.

Plutôt que d'étendre le contrôle FormView pour y inclure la référence à l'entité, nous préférons implémenter un contrôle utilisateur nommé ProjetEditor qui pourrait être généré à l'avenir par notre usine à partir du modèle objet.

<uc1:ProjetEditor ID="_ProjetEditor" runat="server" />
public partial class ProjetEditor : UserControl, IProjetContainer

Dans l'écran associé à la question, nous déclarons comme éléments visuels :

  • le contrôle utilisateur : ProjetEditor
  • deux boutons pour valider ou annuler la saisie : NextButton, CancelButton

La page ASP.NET implémente également l'interface contenant l'entité à manipuler :

public partial class ProjetAskInfos : Page, IProjetContainer

Et le lien avec le contrôle utilisateur "coule de source" :

public Projet Projet
{
    get { return _ProjetEditor.Projet; }
    set { _ProjetEditor.Projet = value; }
}

Il nous reste à brancher le contrôleur qui gère l'exécution de l'activité :

private IActivityController ActivityController
{
    get { return ActivityControllersSessionStack.Instance.Peek(); }
}

Ce qui est fait à chaque chargement de la page :

protected void Page_Load(object sender, EventArgs e)
{
    ActivityController.Execute(); 
}

Enfin, à travers les évènements déclenchés par un clic sur les boutons, le contrôleur assure le passage à l'état suivant ou l'annulation de l'activité :

protected void NextButton_Click(object sender, EventArgs e)
{
    if (Page.IsValid)
        ActivityController.Execute(ActivityStateResult.Next);
}

protected void CancelButton_Click(object sender, EventArgs e)
{
    ActivityController.Execute(ActivityStateResult.Cancel);
}

Nous voilà donc avec une implémentation pour une IHM web de la question qui contient uniquement de la connectique avec les autres couches. Il nous manque encore un branchement, est-ce que vous voyez lequel ?

Si oui, vous avez gagné... toute notre estime !

Nous aurons l'occasion d'y revenir mais l'essentiel est d'avoir pu pratiquer à travers ce prototype d'écran la mise en oeuvre du principe de séparation entre la logique métier et la présentation, approche qui nous permet avec le temps de satisfaire notre préoccupation de développer une application modulaire et évolutive.

Nous sommes maintenant prêts à nous jeter véritablement à l'eau et nous lancer dans l'équipée du développement d'une application métier avec Salamanca. En bon capitaine, nous rendrons bientôt compte des conditions de notre départ dans ce carnet de bord.