Salamanca

Alpha 2 : les énumérations [A bord de Salamanca]

Mon, 31 Aug 2009 07:00:00 -0700

La sortie de la version alpha 2 de Salamanca nous a donné l'occasion de sortir notre équipement pour révision en cale sèche...

Spécification du cycle de vie d'un projet

La principale amélioration apportée par Salamanca alpha 2 étant le support des énumérations dans le modèle entité, nous en avons profité pour revoir et implémenter le cycle de vie d'un projet suivant :

Chaque changement de statut est de la responsabilité d'un des interlocuteurs que nous avons déjà spécifié lors de la modélisation de nos entités :

Un client soumet un projet
Un commercial prend en charge ou annule un projet soumis
Le client détaille le besoin de son projet pris en charge
Un consultant prototype un périmètre délimité du besoin
Le client clôture le projet après livraison du prototype

Modélisation avec énumération

Pour modéliser le cycle de vie d'un projet, nous avons ajouté l'énumération StatutProjet dans notre modèle entité et défini chaque statut du cycle en tant que valeur, avec comme type sous-jacent une chaîne de 5 caractères. Nous avons alors ajouté l'attribut Statut à l'entité Projet et défini son type comme StatutProjet.

Pour chaque valeur d'énumération, nous associons à travers le champ Description de ses propriétés la chaîne de caractères "en français" : Soumis, Pris en charge, Détaillée, Prototypé, Clôturé, Annulé.

On retrouve alors dans le code SQL généré l'insertion de ces valeurs en base :

INSERT INTO StatutProjet VALUES('SOUMI', 'Soumis');
INSERT INTO StatutProjet VALUES('ENCHA', 'Pris en charge'); 
INSERT INTO StatutProjet VALUES('DETAI', 'Détaillé');
INSERT INTO StatutProjet VALUES('PROTO', 'Prototypé'); 
INSERT INTO StatutProjet VALUES('CLOTR', 'Clôturé');
INSERT INTO StatutProjet VALUES('ANNUL', 'Annulé');

Implémentation de l'écran liste des projets

Afin d'avoir une vue d'ensemble des projets client, un commercial doit pouvoir visualiser la liste des projets et leur statut dés la page d'accueil de son espace.

Nous ajoutons donc dans le projet Eproject.Web :

un répertoire Espace qui regroupe les écrans accessibles après ouverture de session
une page d'accueil Default.aspx qui affiche une vue d'ensemble selon le rôle utilisateur

Dans la page d'accueil, nous implémentons la liste des projets à travers :

un contrôle ASP.NET GridViewaffichant les projets sous forme de tableau
un contrôle ASP.NET SqlDataSource récupérant les informations directement avec une requête SQL vers la base de données

Pour accéder à la base de données, nous configurons une chaîne de connexion avec l'utilitaire Enterprise Library Configuration de la même façon que pour notre projet de tests unitaires. Le résultat placé dans le fichier web.config du projet web est le suivant :

<dataConfiguration defaultDatabase="eProject_ABord" />
<connectionStrings>
  <add name="eProject_ABord" connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=eProject_ABord;Integrated Security=True" providerName="System.Data.SqlClient" />
</connectionStrings>

Pour alimenter la liste, nous ajoutons des données de test dans la base eProject_ABord avec le script SQL :

Declare @client_id uniqueidentifier=newid();

INSERT INTO Interlocuteurs (Id, Nom, Email) VALUES (@client_id, 'Client test', 'client@test.com'); 
INSERT INTO Clients (Id, Societe) VALUES (@client_id, 'Société test');

INSERT INTO Projets (Client_Id, Nom, Statut_Code) VALUES (@client_id, 'Application DA VINCI', 'SOUMI'); 
INSERT INTO Projets (Client_Id, Nom, Statut_Code) VALUES (@client_id, 'Gestion de stocks', 'SOUMI');
INSERT INTO Projets (Client_Id, Nom, Statut_Code) VALUES (@client_id, 'Projet SIGMAT', 'ENCHA'); 
INSERT INTO Projets (Client_Id, Nom, Statut_Code) VALUES (@client_id, 'Plateforme YaKa', 'DETAI');
INSERT INTO Projets (Client_Id, Nom, Statut_Code) VALUES (@client_id, 'Fiche PATROL', 'PROTO'); 
INSERT INTO Projets (Client_Id, Nom, Statut_Code) VALUES (@client_id, 'MOBILAT', 'CLOTR');
INSERT INTO Projets (Client_Id, Nom, Statut_Code) VALUES (@client_id, 'Projet SPAMMER', 'ANNUL');

Dans un fichier de ressource nommé Sql.resx ajouté au dossier ASP.NET App_GlobalResources, nous définissons la requête SQL ProjectSelectList :

SELECT p.Id, p.Client_Id, p.Nom, c.Societe, sp.Description
FROM Projets p, Clients c, StatutProjet sp 
WHERE  p.Client_Id=c.Id AND p.Statut_Code=sp.Code

Dans la page web, nous ajoutons le code ASP.NET ci-dessous pour afficher la liste issue de la requête :

<asp:SqlDataSource ID="ProjetSqlDataSource" runat="server" 
ConnectionString="<%$ ConnectionStrings:eProject_ABord %>" ProviderName="<%$ConnectionStrings:eProject_ABord.ProviderName %>" 
SelectCommand="<%$ Resources:Sql, ProjetSelectList %>">
</asp:SqlDataSource> 
<asp:GridView ID="ProjetGridView" runat="server" DataSourceID="ProjetSqlDataSource" DataKeyNames="ID" Width="400px">
    <Columns> 
        <asp:BoundField DataField="Id" HeaderText="Id" ReadOnly="True" SortExpression="ID" Visible="False" />
        <asp:BoundField DataField="Nom" HeaderText="<%$ Resources:SR, ProjetNomLabel %>" /> 
        <asp:BoundField DataField="Societe" HeaderText="<%$ Resources:SR, ClientSocieteLabel %>" />
        <asp:BoundField DataField="Description" HeaderText="<%$ Resources:SR, ProjetStatutLabel %>" /> 
    </Columns>
</asp:GridView>

Pour obtenir un "look & feel" homogène dans notre application, nous avons ajouté :

la page maître Site.Master liée à une feuille de style CSS placée dans le thème Default du répertoire ASP.NET App_Themes
un fichier d'apparence grid.skin également placé dans le thème Default définissant le style par défaut d'un contrôle GridView
l'option styleSheetTheme="Default" à la directive pages du fichier web.config

La page Default.aspx est transformée en formulaire de contenu web en ajoutant :

la directive MasterPageFile="~/Site.master"
le code ASP.NET dans un contrôle Content associé à la région pour le contenu (ContentPlaceHolder) définie dans la page maître

Nous obtenons ainsi la liste des projets avec leur client et leur statut associés sous la forme suivante :

Mise à jour des références Salamanca

Le refactoring des bibliothèques réalisé dans la mise à jour alpha 2 de Salamanca nous a permis lors de cette révision de réduire le nombre de références dans notre projet.

Par exemple, dans le projet Eproject.Model, nous avions les 4 références suivantes :

Salamanca.Common
Salamanca.DataAccess
Salamanca.DataAccess.EnterpriseLibrary
Salamanca.DataRules

Nous n'avons maintenant plus que 2 références :

Salamanca
Salamanca.EnterpriseLibrary.4

Ce passage en "révision" de notre équipée nous a donc permis d'enrichir notre modèle graphique des entités avec la description du cycle de vie d'un projet ainsi que que de l'illustrer simplement à travers l'implémentation d'un écran web accédant directement à la base de données.

Il est bientôt temps de repartir à l'aventure pour mettre en oeuvre des interactions entre l'application et l'utilisateur à travers des activités métier...

Contrôle des papiers... [A bord de Salamanca]

Wed, 19 Aug 2009 07:01:00 -0700

En quittant notre dernière escale, nos hôtes nous ont demander de présenter des informations validées sur notre équipée. Heureusement, nous avons dans Salamanca une bibliothèque qui permet de vérifier aisément la saisie de données : Data Rules !

Pour rendre un système d'information utile et efficace, il ne suffit pas de l'alimenter en données, il faut aussi en assurer la cohérence.

La première exigence qui en découle est de valider les informations fournies si possible dés leur saisie et avant leur sauvegarde dans la base de données.

Dans le modèle entité dessiné avec Salamanca, on peut associer à chaque attribut des règles de validation prédéfinies en fonction de spécifications métier telles que :

valeur par défaut ; par exemple, le statut du projet est "Nouveau" par défaut
autorisation de la valeur null ; par exemple, un projet doit avoir un nom
longueur maximum ; par exemple, le nom du projet ne dépasse pas 32 caractères

Ces propriétés sur les attributs d'une entité constituent le premier niveau de règles métier. Elles sont implémentées non seulement dans la base de données sous forme de contraintes, mais aussi dans la couche objet sous forme d'attributs (au sens .NET) liés aux propriétés de l'objet. Par exemple :

[NotNullRule]
[StringLengthRule(32)]
public string Nom
{
...
}

Profitons d'avoir configuré notre projet de tests pour valider que ces règles métier sont vérifiées lors de la sauvegarde d'un projet.

Pour faciliter l'exécution de notre série de tests, nous initialisons chacun avec des données valides pour une instance de Projet défini pour la classe de test :

[TestInitialize()]
public void MyTestInitialize()
{
 Client c = new Client(DataMappers); 
 c.Nom = "Jean Dupond";
 Projet = new Projet(c, DataMappers);
 Projet.Nom = "Mon projet";
}

Pour tester que le nom saisi dépasse la longueur maximale, nous ajoutons un test avec "un nom de projet vraiment trop long" et nous vérifions que

la méthode Validate(string propertyName) d'un objet DomainEntity renvoit FAUX
qu'une BrokenRulesException est levée lorsqu'on sauvegarde une instance non valide

[TestMethod]
[ExpectedException(typeof(BrokenRulesException))]
public void CannotValidateNomNull()
{
    Assert.IsTrue(Projet.Validate());
    Projet.Nom = null;
    Assert.IsFalse(Projet.Validate("Nom"));
    Projet.Save();
}

Le code complet de notre classe se résume à la validation d'une série de 3 tests :

On doit pouvoir sauvegardé une instance de Projet avec un nom valide
On ne doit pas pouvoir sauvegardé une instance de Projet avec un nom vide (NULL)
On ne doit pas pouvoir sauvegardé une instance de Projet avec un nom trop long (> 32 caractères)

using Microsoft.VisualStudio.TestTools.UnitTesting;
using Salamanca.DataRules;
using NourY.Eproject.Model;

namespace NourY.Eproject.Tests.Model
{
    [TestClass]
    public class ProjetTest : UnitTestBase, IProjetContainer
    {
        [TestMethod]
        [DeploymentItem("..\\eProject_ABord_Tests.mdf")]
        public void CanSaveAndValidateProjet()
        {
            Assert.IsTrue(Projet.Validate());
            Projet.Save();
        } 

        [TestMethod]
        [ExpectedException(typeof(BrokenRulesException))]
        public void CannotValidateNomNull()
        {
            Assert.IsTrue(Projet.Validate());
            Projet.Nom = null;
            Assert.IsFalse(Projet.Validate("Nom"));
            Projet.Save();
        } 

        [TestMethod]
        [ExpectedException(typeof(BrokenRulesException))]
        public void CannotValidateNomTooLong()
        {
            Assert.IsTrue(Projet.Validate());
            Projet.Nom = "Un nom de projet vraiment trop long";
            Assert.IsFalse(Projet.Validate("Nom"));
            Projet.Save();
        } 

        [TestInitialize()]
        public void MyTestInitialize()
        {
            Client c = new Client(DataMappers);
            c.Nom = "Jean Dupond";
            Projet = new Projet(c, DataMappers);
            Projet.Nom = "Mon projet";
        } 

        public Projet Projet
        {
            get { return _Projet; }
            set { _Projet = value; }
        } 

        private Projet _Projet;
    }
}

Les règles de validation sur les attributs des entités s'avère donc non seulement aisées à mettre en place mais également implémentées de manière concise dans la couche objet. Pour valider des champs avec des règles avancées tels qu'une adresse email, un numéro de téléphone ou un code postal, nous pouvons exploité la puissance des expressions régulières à travers des règles de type RegexRule.

Cette exploration "forcée" de la bibliothèque DataRule entre deux escales nous ouvre déjà un horizon bien dégagé du côté de la consolidation des données de nos applications métier. A suivre avec leur utilisation dans le cadre d'activités métier...

Escale #3 : Tests unitaires [A bord de Salamanca]

Mon, 10 Aug 2009 00:47:00 -0700

Nous avons maintenant une base de données à notre disposition. Mais ne perdons pas de vue le but de notre expédition, ou plutôt l'enchainement de buts : apprendre à utiliser Salamanca afin, in fine, de mettre en place un processus métier qui produit de la valeur.

Mais comme dans la fable du lièvre et de la tortue, nous prenons le temps de mettre en place des bonnes pratiques de développement en cours de route afin d'assurer à la fois la qualité de notre produit et la facilité de sa maintenance.

L'escale d'aujourd'hui s'attarde sur la mise en place des outils de contrôle de la qualité : les Tests.

Contexte

Même si nous parlons de tests unitaires, notre intention est plutôt de s'assurer que le code produit est conforme au résultat attendu, par exemple que les règles métier définies sont bien respectées. Dans la terminologie du test informatique, on parle alors de tests fonctionnels (de recette ou encore d'acceptation) par opposition aux tests techniques (unitaires, d'intégration, système, performance, ...).

Mais dans notre cas, nous nous appuyons sur le framework de test de Visual Studio. C'est pourquoi nous avons créé le projet Eproject.Tests lors de la mise en place de la solution (cf L'application Salamanca).

Configuration

Comme l'objet de notre application est de manipuler des données, nous avons besoin d'une base de données dédiée pour les tests qui puisse être recréée à chaque exécution d'un jeu de tests. Pour cela, nous procédons de la même manière que pour la base de données de développement, avec une étape supplémentaire :

création d'une base de données SQL Server 2008 Express
copie du fichier de base de données dans le projet de tests

Cette procédure peut se traduire sous forme de la commande batch CreateTests.cmd, placée dans le répertoire Create Scripts du projet Eproject.Sql :

SET CONNECT_STRING=.\SQLEXPRESS 
SET BASE_NAME=eProject_ABord_Tests 
SET TestsDir=%CD%\..\..\Eproject.Tests

sqlcmd.exe -E -X -S %CONNECT_STRING% -v DatabaseName=%BASE_NAME% -i Create.sql

xcopy "C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA\%BASE_NAME%.mdf" %TestsDir% /y 
xcopy "C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA\%BASE_NAME%_log.ldf" %TestsDir% /y

Une fois le fichier de base de données copié, nous l'ajoutons dans notre projet ("Afficher tous les fichiers", clic droit sur le fichier, puis "Inclure dans le projet").

La configuration de sa chaîne de connexion est facilité par l'utilisation du Data Application Block du framework Microsoft Enterprise Library (cf Pré-requis). Pour cela, nous utilisons :

un fichier de configuration app.config ajouté dans notre projet
l'utilitaire Enterprise Library Configuration

On obtient ainsi le code de configuration suivant :

<configuration> 
  <configSections> 
    <section name="dataConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DatabaseSettings, Microsoft.Practices.EnterpriseLibrary.Data, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> 
  </configSections> 
  <dataConfiguration defaultDatabase="eProject_ABord_Tests" /> 
  <connectionStrings> 
    <add name="eProject_ABord_Tests" connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|eProject_ABord_Tests.mdf;User Instance=true" 
      providerName="System.Data.SqlClient" /> 
  </connectionStrings> 
</configuration>

Codage

Pour pouvoir coder des tests qui manipulent des instances des entités métier que nous avons modélisé, nous aurons besoin d'une collection de DataMapper, dont le rôle (tel que je l'ai assimilé) est de servir de point d'ancrage de la couche de persistence, à savoir la gestion du cache et des échanges entre les instances d'objets en mémoire et leur structure de stockage en base de données (cf QuickStart : the Domain Model).

L'implémentation choisie est d'avoir une classe de base dont tous les tests hériterons. C'est une classe publique contenant une propriété de type DataMapperCollection avec un getter sous forme de singleton tirant parti des facilités offertes par les bibliothèques Enterprise Library et DataAccess pour créer une connexion avec la base de données (configurée par défaut dans app.config) ainsi qu'un mode de cache des données (dans notre cas, elles ne seront pas conservées en mémoire).

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;
using Microsoft.Practices.EnterpriseLibrary.Data;
using Salamanca.DataAccess;
using Salamanca.DataAccess.Collections;
using NourY.Eproject.Model.Mappers.EnterpriseLibrary;

namespace NourY.Eproject.Tests
{
 public class UnitTestBase
 {
 public UnitTestBase()
 {
 }

 protected DataMapperCollection DataMappers
 {
 get
 {
 if (_DataMappers == null)
 _DataMappers = Mappers.CreateDataMapperCollection(
 DatabaseFactory.CreateDatabase(), 
 new NoCacheManager());
 return _DataMappers;
 }
 }

 private DataMapperCollection _DataMappers;
}

Pour pouvoir compiler notre projet, nous avons ajouté les références aux bibliothèques contenant les types utilisés dans notre classe de base :

DatabaseFactory dans EnterpriseLibrary.Data
NoCacheManager et DataMapperCollection dans DataAccess
Mappers dans Eproject.Model

Voici venu le temps de tester notre configuration à travers un exemple simple : je veux pouvoir sauvegarder le projet nommé "Projet Test" du client nommé "Client Test".

Nous ajoutons le test unitaire CrudProjetTest qui hérite de la classe UnitTestBase. Afin d'avoir une base de données "propre" à chaque exécution, nous l'associons à notre classe de test à travers l'attribut DeploymentItem.

 [TestClass]
 [DeploymentItem("..\\eProject_ABord_Tests.mdf")]
 public class CrudProjetTest : UnitTestBase
 {
 [TestMethod]
 public void CanSaveProjet()
 {
 Client c = new Client(DataMappers);
 c.Nom = "Projet Test";
 Projet p = new Projet(c, DataMappers);
 p.Nom = "Client Test";

 Assert.IsTrue(p.IsModified);
 p.Save();
 Assert.IsFalse(p.IsModified);
 }
 }

Nous vous invitons à tester cette configuration dont le réel intérêt est à terme de pouvoir valider que l'implémentation des activités métier de notre application s'exécute avec succès et respectent les règles métier définis. Mais avant cela, nous verrons évidemment comment concevoir et coder les activités métier, concept essentiel de Salamanca...

Escale #2 : Base de données [A bord de Salamanca]

Fri, 31 Jul 2009 01:42:00 -0700

Pourquoi avoir spécifié, modélisé et généré des entités métier ?

Si nous sommes à bord de Salamanca, c'est car nous voulons informatiser (et améliorer) l'un de nos processus de travail. L'objectif est de permettre aux acteurs de ce processus de consulter, saisir, évaluer, récupérer ou exploiter les ressources et informations alimentant ce processus dans le cadre d'un enchaînement d'activités.

C'est d'ailleurs la base de la définition d'une application métier :

"manipuler des données spécifiques à une organisation ou un secteur d'activité".

Nous sommes donc en accord avec la ligne de produits ciblée par l'usine Salamanca (ça tombe bien !). Pour cela, un moyen de stocker l'ensemble de ces informations nous est nécessaire.

Comme Salamanca comprend une bibliothèque ORM (mais pas seulement !), l'implémentation du mapping entre notre modèle d'entités métier et le modèle physique des données est pour nous, humble développeur "métier", transparent (même s'il est toujours conseillé d'avoir une compréhension haut niveau des concepts associés).

Nous nous attarderons donc lors de cette escale uniquement sur l'organisation que nous avons mis en place pour créer (et re-créer) rapidement notre base de données.

Organisation

Puisque nous disposons du code SQL généré pour la création des tables et des procédures stockées CRUD, autant en profiter. Néanmoins, leur emplacement dans le projet Model et leur liaison au fichier modèle (.tt) assurant leur génération ne permettent pas de les dinstinguer facilement dans notre solution Visual Studio. C'est pourquoi nous avons ajouté le projet Eproject.Sql de type Projet de base de données lors de la création de notre solution (tout s'explique !).

Ainsi, chaque développeur dispose de sa propre base de données de développement à partir d'un schéma placé dans le gestionnaire de versions (conformément aux bonnes pratiques) et "bien rangé" dans l'environnement de travail :

les scripts de création : dans Create Scripts
les scripts de mise à jour : dans Change Scripts

Pour cela, nous ajoutons dans les propriétés du projet Eproject.Model un évènement après génération (Post-build) afin de copier les fichiers SQL générés dans leur répertoire cible.

De cette façon, les scripts servant à la création de la base restent synchronisés après chaque mise à jour du modèle, puis compilation du code généré.

Remarque : la première fois, pensez à ajouter manuellement les fichiers copiés (clic droit sur le répertoire, puis "Ajouter un élément existant...").

Automatisation

Pour automatiser la création de notre base de données, nous avons besoin :

d'un script TRANSACT-SQL pour effacer (si nécessaire) et créer la base
d'exécuter l'utilitaire sqlcmd en ligne de commande ou dans un batch (.cmd)

Nous pourrions pousser l'automatisation de la même façon que pour la copie des fichiers SQL en ajoutant un évènement après génération du projet Eproject.Model. Mais cela efface les données saisies en cours de développement à chaque génération, donc nous préférons nous placer dans le répertoire Create Scripts et exécuter la commande ci-dessous (dans un batch) uniquement lors d'un changement dans notre schéma :

C:\eProject\src\ABordDeSalamanca\Eproject.Sql\Create Scripts>sqlcmd.exe -E -X -S .\SQLEXPRESS -v DatabaseName=eProject_ABord -i Create.sql

Comme nous utilisons une base de données SQL Server 2008 Express, notre exemple de script TRANSACT-SQL contient le code suivant :

USE master
GO

IF EXISTS (SELECT * FROM sys.databases WHERE name=N'$(DatabaseName)')
BEGIN
 ALTER DATABASE $(DatabaseName)
 SET SINGLE_USER
 WITH ROLLBACK IMMEDIATE
 DROP DATABASE $(DatabaseName)
END
GO

CREATE DATABASE $(DatabaseName)
GO

USE $(DatabaseName)
GO

:reset 
:r Tables.sql 
:r StoredProcedures.sql 
GO

Voilà une façon rapide de disposer à tout moment d'une base de données synchronisée avec notre modèle d'entités métier. Et nous verrons lors de notre prochaine escale comment la mise en place de notre projet de tests unitaires en bénéficie...

Escale #1 : Entités métier [A bord de Salamanca]

Mon, 27 Jul 2009 08:37:00 -0700

Nous voilà arrivés au pays des "entités". Mais qui sont-elles ?

Pour mieux intégrer cette notion d'entité, nous nous référons à sa définition dans le cadre du modéle entité-relation développé par Dr Peter Chen :

"une chose qui peut être identifiée distinctement ayant une signification pour une organisation".

Spécification

Dans le cadre du service que nous développons, eProject, nous voulons mettre en relation les entités suivantes :

un projet métier : vue d'ensemble, besoin détaillé et périmètre d'un prototype
3 interlocuteurs : client, commercial et consultant

Lors de la définition de notre besoin, nous avons également précisé les règles d'association à travers les spécifications suivantes :

Pour consulter NourY Solutions sur mes besoins métier, je veux pouvoir soumettre mon projet ainsi que mes projets ultérieurs en tant qu'interlocuteur client
Pour piloter la relation clientèle, je prend en charge le suivi de l'avancement des projets de chacun de mes clients en tant qu'interlocuteur commercial
Pour produire un prototype à partir de l'analyse d'un besoin, je veux pouvoir estimer la charge de travail sur la base de chaque projet en tant qu'interlocuteur consultant

Modélisation

Une fois les concepts digérés et notre besoin spécifié, Salamanca nous permet de rapidement modéliser le socle de notre métier représenté dans le diagramme ci-dessus.

Pour cela, nous ouvrons le modèle SDML du projet Eproject.Model de la solution Visual Studio créée lors de notre départ.

La palette d'éléments mise à disposition dans la boite à outils est d'une aide précieuse pour implémenter notre modèle de 5 entités simplement par glisser-déposer et définition des propriétés des associations :

1 composition entre Client et Projet
2 associations bidirectionnelles entre Commercial et Client, entre Consultant et Projet
3 héritages : Client, Commercial et Consultant sont tous des Interlocuteurs du Projet

Nous pouvons maintenant définir les attributs soit par glisser-déposer de l'élément "Attribute" à partir de la boîte à outils, soit par clic droit sur l'entité, puis "Ajouter un nouveau Entity Attribute" à partir du menu contextuel.

Le nom et le type (string par défaut) de l'attribut peuvent être définis directement de manière graphique alors que la fenêtre de "Propriétés" permet également de spécifier des règles validées automatiquement grâce à l'utilisation de l'une des 4 bibliothèques de Salamanca : Data Rules.

La facilité d'intégration de règles métier est l'une des grandes forces de Salamanca, aussi nous lui dédierons bientôt une escapade de découverte avant la prochaine escale !

Génération

Une fois les attributs et les règles associées définis pour chaque entité, il nous reste qu'à générer le code correspondant par un simple clic sur l'icône "Transformer tous les modèles" présente dans la barre d'outils de la fenêtre "Explorateur de solutions".

A la fin de la génération, nous obtenons l'ensemble du code de la couche d'accès aux données basé sur la bibliothèque générique de Salamanca dédié à cet usage : Data Access. Cette couche est constituée :

du code SQL de création des tables associées aux entités
des procédures stockées pour les opérations CRUD sur chaque entité
des interfaces et classes de mapping entre entités et tables (Data Mappers)
des ressources liant procédures stockées et méthodes CRUD implémentées dans les Data Mappers
des interfaces et classes des entités du domaine métier

L'avantage évident de cette formule "Modélisation + Génération" est de ne plus avoir à taper du code redondant. Pour preuve, je vous invite à satisfaire votre curiosité et éditer les fichiers générés : on retrouve le même air dans chaque classe avec quelques variations autour du thème...

Mais le réel instant de bonheur du point de vue du développeur se savoure lors de l'implémentation de demandes d'évolutions telles que l'ajout d'attributs, ou mieux, lors de la modification de relations. Personnellement, j'ai par le passé consommé beaucoup de temps dans la maintenance du code SQL et objet suite aux évolutions inhérentes à tout projet métier.

Je vous invite donc dés maintenant à faire l'expérience avec le modèle métier de votre projet en cours avant notre prochaine escale : l'automatisation de la mise en place de la base de données.

Salamanca 1.0.1 (alpha 2) is released [The road to Salamanca]

Thu, 16 Jul 2009 08:46:00 -0700

The second version of Salamanca has just been released : 1.0.1 (alpha 2).

Changes from the previous release include :

A complete refactoring of the libraries : all the base classes are now grouped together in a single assembly (Data Rules, Data Access and Data Activities), available in 2 editions (.NET Framework and .NET Compact Framework). Additional assemblies are available for the use of external libraries (Enterprise Library).
The concept of enumerations has been added to the SDML designer.
Many bug fixes.

Note that you will have to uninstall the previous version of Salamanca before installing this one.

There are a few things to be noted about the new enumerations :

Enumerations defined in the SDML can obviously be used as data types for entity attributes.
Enumerations have an underlying type (pretty much like in C#). This defines how enumerated values will be stored in the database.
An enumeration translates into a lookup table in the database (each tuple matching an enumerated value).
An underlying value must be provided for every enumerated value (this is optional in C#).
The default underlying type for an enumeration is a string (impossible in C#). This allows for the use of mnemonics in the database. Your DBA will thank you for this !

And as a conclusion, here is a short list of features that are planned on our roadmap to a final release :

Multi database provider SQL code generation : we should at least be able to generate code for Oracle systems.
A first pick at a SAML designer. Salamanca looks a lot like (yet) an (other) ORM framework right now, but this is not all there is to it. The ability to design activities (that may use our entities) will bring huge benefits to developers and will show what our vision truly holds.

But for now, enjoy this release. And any feedback will be more than welcome !

Released: 1.0.1 (alpha 2) (Jul 16, 2009) [CodePlex]

Thu, 16 Jul 2009 06:17:11 -0700

This software is an alpha release and as such it is not suited for use in production (read : critical) environments.

This is the second release of Salamanca as a Software Factory :

Completely integrated into the Visual Studio 2008 environment (with an installer).
Documentation integrated in Microsoft Document Explorer (and also available as a separate download).
Includes a SDML designer, with code generation :
- Domain entities (.NET Framework 3.5).
- Data mappers (based on Enterprise Library 4.1, .NET Framework 3.5).
- SQL scripts for tables creation and stored procedures for CRUD access (SQL Server 2005, 2008).
Libraries (Data Rules, Data Access and Data Activities), targeting the .NET Framework (2.0, 3.0 and 3.5) and the .NET Compact Framework (2.0 and 3.5) (and also available as a separate download).

Changes from the previous release include :

Complete refactoring of the libraries : all the base classes are now grouped together in a single assembly (Data Rules, Data Access and Data Activities), available in 2 editions (.NET Framework and .NET Compact Framework). Additional assemblies are available for the use of external libraries (Enterprise Library).
The concept of enumerations has been added to the SDML designer.
Many bug fixes.

Please note that upgrade from the previous version is unsupported. You will have to uninstall any prior version of Salamanca before installing this version.

Related Resources

Installation manual.
Quick Start.

Larguez les amarres ! [A bord de Salamanca]

Wed, 01 Jul 2009 08:16:00 -0700

Au moment de larguer les amarres, il y a toujours sur le quai un ami ou un passant pour nous demander si rien n'a été oublié et que tout a été chargé...

Pré-requis

Pour démarrer, nous avons bien sûr téléchargé la dernière version 1.0 (alpha) de Salamanca à l'adresse :

http://salamanca.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=24562

Suivant le manuel d'installation, nous avons d'abord vérifié que notre équipement contient déjà Visual Studio 2008 SP1 dont la version d'évaluation de l'édition Professionnal est téléchargeable à l'adresse :

http://www.microsoft.com/downloads/details.aspx?familyid=83C3A1EC-ED72-4A79-8961-25635DB0192B&displaylang=fr

Nous avons ensuite téléchargé et installé les Guidance Automation Extensions (GAX) à l'adresse :

http://www.microsoft.com/downloads/details.aspx?familyid=DF79C099-4753-4A59-91E3-5020D9714E4E

Comme nous souhaitons utiliser les facilités offertes par le Data Access Application Block, nous avons aussi téléchargé Enterprise Library 4.1 à l'adresse :

http://www.microsoft.com/Downloads/details.aspx?familyid=1643758B-2986-47F7-B529-3E41584B6CE5

Nous utiliserons également une base de données SQL Server 2008 Express disponible avec l'outil SQL Server 2008 Management Studio Express à l'adresse :

http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=7522a683-4cb2-454e-b908-e805e9bd4e28

L'application Salamanca

Nous voilà parés pour monter à bord de Salamanca. Notre périple commence par la création de notre application eProject dans notre environnement de développement Visual Studio.

Nous respectons ensuite (presque) les conventions de nommage de mise en majuscule de notre langage préféré C# dans la définition du nom de domaine de l'application.

Nous obtenons ainsi une solution Visual Studio constituée du projet Eproject.Model de type Bibliothèque de classes qui nous permettra de modéliser les concepts métier de notre application et de générer l'ensemble du code associé :

classes des entités métier
classes de mapping objet-relationnel (DataMappers)
scripts SQL de création des tables et procédures stockées de la base de données

Afin d'avoir les provisions nécessaires à notre voyage, nous ajoutons dés maintenant à la solution Visual Studio les projets pour chaque composant à fabriquer. Notre application Salamanca est alors composée de :

Eproject.Model de type Bibliothèque de classes pour la modélisation et la génération des entités métier
Eproject.Sql de type Projet de base de données pour la création et maintenance des scripts SQL
Eproject.Tests de type Projet de test pour la création et l'exécution des tests unitaires
Eproject.Activities de type Bibliothèque de classes pour le codage des activités métier
Eproject.Web de type Application Web ASP.NET contenant l'implémentation web des activités ainsi que la définition de la présentation à travers :
- une page maître
- un thème ASP.NET
- les ressources de localisation
Eproject.Setup de type Projet d'installation Web pour le déploiement de l'application

Nous ajoutons l'arborescence des fichiers créés à partir de cette structure de base dans notre gestionnaire de versions (Subversion) qui sert de référentiel pour l'ensemble de nos codes sources.

Nous voilà munis d'un équipement bien outillé et d'un bel horizon devant nous.

Lors de notre prochaine escale, vous verrez comment nous tirons profit du bon vent que nous amène la modélisation des entités et la génération du code associé.

Tâchons de garder le cap !

Bye bye World! [A bord de Salamanca]

Mon, 29 Jun 2009 02:30:00 -0700

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

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 :

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.

Préparation [A bord de Salamanca]

Mon, 22 Jun 2009 08:30:00 -0700

Maintenant que nous avons fait connaissance avec l'équipement (Salamanca), l'équipage (votre dévoué capitaine) et l'équipée (mon projet), nous allons préparer notre itinéraire, histoire de ne pas partir pour l'inconnu.

Plutôt que fixer une destination, nous préfèrons vous embarquer pour une croisière (à vous de voir si elle s'amuse).

Elle aura pour escales :

Organisation de la solution Salamanca dans Visual Studio
Génération du code pour le modèle des entités métier
Création de la base de données
Configuration du projet de tests unitaires
Conception du modèle et codage d'une activité métier
Implémentation web d'une activité métier
Mise en place du déploiement de l'application web

Une fois cet itinéraire bouclé, nous prévoyons déjà de le réitérer afin d'améliorer notre connaissance du parcours grâce à l'expérience acquise et d'exploiter les évolutions futures de l'équipement.

Nous serons peut-être aussi amené à dériver vers d'autres rivages au gré des vents rencontrés entre chaque escale.

N'hésitez pas également à faire part d'autres voies à explorer.

Mais avant de partir avec ce plan de route, nous allons nous mettre en situation et tester notre "bateau" avec un essai en "eaux calmes" à travers :

Prototypage d'un formulaire ASP.NET avec et sans Salamanca

Et pour se mettre en condition, rien de tel qu'un air d'heureux présage.

Georges Brassens - Heureux qui comme Ulysse

New blog in town [The road to Salamanca]

Fri, 19 Jun 2009 06:47:00 -0700

Good news (if you understand French, that is) : Pierre just opened a new blog about Salamanca today called A bord de Salamanca (and yes, it’s in French). In his first post, he says he will, as a Salamanca user, share his experience about Salamanca (some bad, but mostly good I hope…). He will also share tips and tricks about using it.

Now is thus the time to reconsider the use of our Salamanca feeds. If you were a subscriber to this blog feed (http://feeds2.feedburner.com/noury/salamanca), you will also automatically get updates about the new blog (as well as various Salamanca related links as we gather them around the web). If you only want to get updates about this blog (due to an allergy to French, for instance), a new feed is available at the address http://feeds2.feedburner.com/noury/salamanca/road. Links on the website will be updated soon.

Welcome aboard !

Embarquement prochain [A bord de Salamanca]

Mon, 15 Jun 2009 06:34:00 -0700

La version 1.0 (alpha 1) de l'usine à logiciels Salamanca est sortie il y a maintenant 3 mois et en tant qu'adopteur de la première heure ("Early adopter"), je compte faire partager à travers ce journal de bord les moments de plénitude comme les mauvais grains que je vis grâce à l'utilisation de cet outil.

Si je fais l'analogie avec une expédition en bateau, c'est que je préfère partir avec une carte et un cap dans ma façon d'aborder mes projets de développement. Je me sens en effet plus comme un poisson dans l'eau dans le rôle d'analyste que dans le rôle de programmeur même si mon CV revendique plusieurs années d'expérience en développement web et mobile sous .NET.

C'est pourquoi je vais aborder la navigation dans le monde de Salamanca à travers l'un des projets sur lequel je travaille depuis maintenant 6 mois : eProject.

Ce service vise à accélérer la prise de décision lors du lancement d'un projet de développement métier. Il s'appuie sur un processus défini de production d'un prototype à partir d'une expression structurée du besoin. L'idée est de mettre entre les mains du porteur de projet une ébauche de solution pour faciliter le soutien et l'implication des différents intervenants.

La mise en oeuvre d'un processus répondant à une problématique métier (dans ce cas le lancement d'un projet) entre directement dans la ligne de produits définie pour l'usine à logiciels Salamanca : les applications métier.

J'attends ainsi de Salamanca qu'elle m'aide à :

développer, faire évoluer et maintenir sur la durée (plusieurs années) un service en ligne dédié aux entreprises
réaliser rapidement (en 1 ou 2 semaines) des prototypes d'application métier

C'est dans ce cadre que je souhaite partager publiquement mon expérience de l'utilisation de Salamanca.

Bienvenue à bord !

Released: 1.0 (alpha 1) (Mar 12, 2009) [CodePlex]

Mon, 16 Mar 2009 10:00:33 -0700

This software is an alpha release and as such it is not suited for use in production (read : critical) environments.

If you have downloaded this software before March 16th 2009, please take a look at this show stopper : Cannot find the generated SqlResource resource at run time

This is the first release of Salamanca as a Software Factory :

Completely integrated into the Visual Studio 2008 environment (with an installer).
Includes a SDML designer, with code generation :

Domain entities (.NET Framework 3.5).
Data mappers (based on Enterprise Library 4.1, .NET Framework 3.5).
SQL scripts for tables creation and stored procedures for CRUD access (SQL Server 2005, 2008).

Updated libraries (Data Rules, Data Access and Data Activities) now targeting the .NET Framework (2.0, 3.0 and 3.5) and the .NET Compact Framework (2.0 and 3.5).

Related Resources

Installation manual.
Quick Start.

Salamanca 1.0 (alpha 1) is released [The road to Salamanca]

Thu, 12 Mar 2009 09:40:00 -0700

Great news today : we just released Salamanca 1.0 (alpha 1) !

As promised, this release includes :

a SDML designer, and code generation :
- Domain entities (.NET Framework 3.5).
- Data mappers (based on Enterprise Library 4.1, .NET Framework 3.5).
- SQL scripts for tables creation and stored procedures for CRUD access (SQL Server 2005, 2008).
Updated libraries, now targeting the .NET Framework (2.0, 3.0 and 3.5) and the .NET Compact Framework (2.0 and 3.5).
Complete Visual Studio 2008 integration (via an installer).

There is still a great deal of work to be done, and you should be aware of some limitations for this release :

Primary keys for the generated entities are Guids (uniqueidentifier on SQL Server). This cannot be changed.
Types for the entities attributes are limited to the following list : bool, DateTime, float, double, int, long, short, Guid and string (by default).
Entities can only be linked by one association at a time. This should cover the vast majority of cases though…

You are welcome to play with our brand new Software Factory and give us any feedback about it. I’ll post later about what the future holds for Salamanca.

We hope you will have a pleasant trip !

Salamanca in words [The road to Salamanca]

Mon, 23 Feb 2009 03:01:00 -0800

It is often said that a picture is worth a thousand words. How about a picture made of words (click on the image to have a larger view) ?

I just gave this blog the Wordle treatment, and the result is quite cool I think. But the best is that two of the words that stand out the most are '”Data” and “Activity”. These are indeed two concepts that lie at the heart of Salamanca.

Released: 0.9.1 (Jan 28, 2009) [CodePlex]

Wed, 28 Jan 2009 08:28:55 -0800

This is a maintenance release for the Salamanca libraries (0.9.0).

Issues closed :

Libraries targeting .NET 2.0 depend on EntLib 4.1 (requires .NET 3.5)

This release contains a new version of the three libraries (Data Rules, Data Access and Data Activities) for the .NET Framework 2.0, the .NET Framework 3.0 and the .NET Compact Framework 2.0. Dependencies for some of these libraries are :

Enterprise Library 3.1 - May 2007.

To help you understand how these libraries typically fit together in a business application, we have set up a quick start, split in two parts :

Part 1 : how to set up a domain model. Based on an overly simple model (1 object, 1 property, 1 database table), we will be able to create our first application, based on our domain model, with virtually no coding.
Part 2 : how to create and implement an activity. Based on the previous domain model, we will implement our first basic activity as an application. We will also show how our activity can easily be unit tested.

Please find more information in our blog.

First maintenance release : 0.9.1 [The road to Salamanca]

Wed, 28 Jan 2009 08:25:00 -0800

We discovered an issue in the current release of the Salamanca libraries (0.9.0) that was important enough to make us deliver a maintenance release : version 0.9.1. You can use these new libraries as a drop in replacement for the old ones.

Note that the issue discovered concerns only the libraries that depend on Enterprise Library :

DataAccess.EnterpriseLibrary : helps to define Data Access Application Block based data mappers.
DataRules.EnterpriseLibrary : helps to integrate the Validation Application Block with the Salamanca rules library.

We previously compiled these libraries against version 4.1 of Enterprise Library, which requires the .NET Framework 3.5. As our libraries were only supposed to target the .NET Framework 3.0 at best, this introduced a very unwelcome dependency. So the new version is compiled against version 3.1 of Enterprise Library, which only requires the .NET Framework 2.0.

As for the next release (1.0.0), these dependencies has been fixed as followed :

.NET Framework 2.0, 3.0 targeted libraries : depend on Enterprise Library 3.1.
.NET Framework 3.5 targeted libraries : depend on Enterprise Library 4.1.

Did I just write about version 1.0.0 ? Here is in two sentences what is to be expected :

updated libraries, now targeting the .NET Framework 3.5 as well.
our first SDML designer ! Still limited, but entirely functional, with code generation from SQL to C# entities…

Stay tuned !

Take the S train [The road to Salamanca]

Fri, 19 Dec 2008 10:58:00 -0800

I've got some news just before the holidays :

the Salamanca repository just got itself a new (shorter) URL : http://salamanca.codeplex.com/, thanks to the CodePlex guys. The old one (that I won't write here) remains valid.
as some of you probably already noticed, Salamanca got itself a logo.

Not so surprisingly, it is a train (the name Salamanca is a reference to The Salamanca, the first commercially successful locomotive built in 1812). The original design for this picture can be found on the Open Clip Art Library.

The streamline design of this engine fits well with the concepts of industrialization that are behind our vision of our Software Factory. And it is also a reference to the excellent Streamlined Object Modeling book. Though our vision of business object implementation differs somewhat from what can be found in this book, their description and analysis of 12 "collaboration patterns" for modeling real-world relationships is an invaluable resource for any person who is involved in modeling activities. As Salamanca users will inevitably be.

Early in the new year to come, you will have the opportunity to exercise your modeling skills on the first version of Salamanca, that will include a SDML graphical designer and code generation. But for now, I've got a train to catch.

To Salamanca via Oslo ? [The road to Salamanca]

Wed, 29 Oct 2008 05:57:00 -0700

Now that our libraries are functional enough, it is high time we started getting into the modeling part of our software factory. The first step is to define proper syntaxes for our DSLs : the Salamanca Domain Model Language (SDML) and the Salamanca Activity Model Language (SAML).

In fact, as a proof of concept, we have already tried to define a syntax for our SDML. Based on XML, it would describe the Domain in terms of types, enumerations, domain elements and associations. Here is an example written in this SDML :

<dml
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns="http://www.nourysolutions.com/salamanca/DML"
 xsi:schemaLocation="http://www.nourysolutions.com/salamanca/DML ../Models/dml.xsd"
>
 <serializable name="string">
 <native type="string"/>
 <sql dbtype="VARCHAR"/>
 </serializable>
 <serializable name="Boolean">
 <native type="bool" nullable="false">
 <conversion language="C#">Convert.ToBoolean({0})</conversion>
 </native>
 <sql dbtype="BOOLEAN">
 <conversion language="C#">Convert.ToByte({0})</conversion>
 </sql>
 </serializable>
 <serializable name="Chars">
 <native type="string"/>
 <sql dbtype="CHAR"/>
 </serializable>
 <serializable name="long">
 <native type="long" nullable="false"/>
 <sql dbtype="BIGINT"/>
 </serializable>
 <serializable name="Date">
 <native type="System.DateTime" nullable="false"/>
 <sql dbtype="DATE"/>
 </serializable>

 <enum name="RegionType">
 <base name="Chars" size="3" />
 <value name="Department" code="DEP">Département</value>
 <value name="State" code="STA">State</value>
 <value name="Land" code="LAN">Land</value>
 </enum>

 <domain name="Region" shortName="Regions">
 <attribute name="Id" visibility="none" required="true">
 <type name="long"/>
 </attribute>
 <attribute name="Name" required="true">
 <type name="string" size="63" />
 </attribute>
 <attribute name="Type" required="true">
 <type name="RegionType" />
 </attribute>
 <key attributes="Id"/>
 </domain>
 <domain name="City" shortName="Cities">
 <attribute name="Id" visibility="none" required="true">
 <type name="long"/>
 </attribute>
 <attribute name="Name" required="true">
 <type name="string" size="63" />
 </attribute>
 <attribute name="HasPostalOffice">
 <type name="Boolean" />
 </attribute>
 <key attributes="Id"/>
 </domain>

 <assoc name="RegionCities" association="composition">
 <end name="Region" target="Region" multiplicity="1"/>
 <end name="Cities" target="City" multiplicity="*"/>
 </assoc>
</dml>

Based on this syntax, we would perform numerous transformations (with XSLT) to generate Visual Studio solutions, projects, source files (SQL, C#), resources and even graphical representation of the domain (by driving the excellent Graphviz). But we found several drawbacks to this method :

XSLT code is tedious to write and hard to debug.
a DSL modification need the manual refactoring of many, hard to maintain files.

And indeed, our code soon became so complex that we had to leave some things out of the generation process, like the implementation of the many to many relationships...

So I started lately to delve into the Visual Studio DSL Tools, armed with my courage, my computer and the appropriate reference. And it looks very promising, though somewhat limited for our grand vision. As Daniel Cazzulino wrote :

The DSL Tools is basically the first step in the road to realizing the full SF vision outlined in The Book. Hence, if you try to build a real-world factory just using DSLs, you will find it fairly incomplete and not supporting typical scenarios such as providing an initial solution structure where you will put your DSLs, etc. The missing features, though, are most probably those that will come (or become unnecessary) as the full vision is implemented. In the meantime, it feels lacking.

Anyway, the first impressions are excellent, and it feels like time invested in designing our DSLs around these tools will be far from being wasted time.

This is how I felt this morning, when I discovered that Microsoft is just starting to communicate about a new product, that they label as a modeling platform, and that is codenamed Oslo. Hear Bill Gates about it :

It's actually taking the kind of models that you're seeing arising in specific domains, like software management in System Center, or your data design over in SQL, or your process activities over in BizTalk and saying, we need to take all these domains and be able to put them into one model space. In fact, we need to let people create their own domains that aren't just isolated, but that exist in this one modeling space. And that's what Oslo is about.

I could not agree more. Salamanca needs to have domain models and activity models in the same modeling space, simply because a business activity is by essence bound to manipulate business objects : a SAML model is linked to a SDML model.

So it looks a lot like Oslo could be the best way to go to Salamanca. That is sure going to be a long journey, but very likely to be an interesting one. For now, I am sticking to my DSL Tools.

QuickStart : the Activity [The road to Salamanca]

Thu, 09 Oct 2008 02:08:00 -0700

Whereas Data Access could be considered as yet another solution to a very common problem (the ORM problem), Data Activities is quite original in its conception and implementation. The concepts involved here are much less refined or complex, but have already proved to be very powerful.

First of all, we have to define an activity in terms of questions and treatments. The simplest activity I could imagine is the following :

this activity is about getting a list of products that match a specified name.
the first state is a question that asks for the name.
the second (and last) state is a treatment that finds the corresponding states.
let's add to this a rule that specifies that the name we are looking for should not be empty (nor null).

For this activity, we'll reuse the Product class we have defined in the Domain Model quick start. The proper way to implement this would be to add a FindByName method to this class and query the database, but we'll do it the Activity way this time.

An activity manipulates data. We need a class to store :

the name of the Product.
the list of products matching that name.

There is a base class in the Salamanca.DataActivities that will help us implement the IActivityData interface :

using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using Salamanca.DataActivities;

namespace QuickStart
{
 public class Data:
 ActivityData
 {
 private struct Backup
 {
 public string Name;
 public Product[] Products;
 }

 protected override object CreateBackup()
 {
 Backup ret=new Backup();
 ret.Name=_Name;
 ret.Products=_Products.ToArray();
 return ret;
 }

 protected override void RestoreBackup(object backup)
 {
 Backup b=(Backup)backup;
 _Name=b.Name;
 _Products=new List<Product>(b.Products);
 }

 public string Name
 {
 get { return _Name; }
 set { _Name=value; }
 }

 public IList<Product> Products
 {
 get { return _Products; }
 set { _Products=new List<Product>(value); }
 }

 private string _Name;
 private List<Product> _Products=new List<Product>();
 }

}

You see there is a bit more than just having a Name and a Products property. When inheriting from ActivityData, you have to implement two abstract methods that create and restore backups on the data. We won't really need this system in this activity, but data must implement IBackupable and this is quite straightforward as you can see in the code above.

Our activity will ask a question. This question is going to be implemented in the UI layer (likely via a TextBox on Windows Forms), so we need a way to allow it to plug itself into our activity. We do that via a question factory, as follows :

using System;
using Salamanca.DataActivities;
using Salamanca.DataActivities.UI;

namespace QuickStart
{
 public abstract class QuestionFactory
 {
 public abstract Question AskProductName(IActivityController controller);
 }
}

Our question state will need this QuestionFactory (or, rather, an implementation of it). And I anticipate that our treatment state will need a DataMapperCollection as we will retrieve all the products from the database via the Product.FindAll method. These are the dependencies of our activities, and we will group them in a parameter class :

using System;
using Salamanca.DataAccess.Collections;
using Salamanca.DataActivities;

namespace QuickStart
{
 public class Parameters:
 IQuestionFactoryParameters<QuestionFactory>
 {
 public Parameters(QuestionFactory factory, DataMapperCollection dataMappers)
 {
 _QuestionFactory=factory;
 _DataMappers=dataMappers;
 }

 public DataMapperCollection DataMappers
 {
 get
 {
 return _DataMappers;
 }
 }

 public QuestionFactory QuestionFactory
 {
 get
 {
 return _QuestionFactory;
 }
 }

 private DataMapperCollection _DataMappers;
 private QuestionFactory _QuestionFactory;
 }
}

We are now ready to create our two states. The first one must implement IActivityInitialState, which is just a marker interface. As a question state, we can simply derive it from the QuestionActivityState base class. The second state just fills our Data with a list of products matching the name that was returned by the question :

using System;
using System.Collections.Generic;
using Salamanca.DataActivities;
using Salamanca.DataActivities.UI;
using Salamanca.DataRules;

namespace QuickStart
{
 public class FindProductListByName:
 QuestionActivityState<Data>,
 IActivityInitialState
 {
 public FindProductListByName(Data data, QuestionFactory factory, DataMapperCollection dataMappers):
 base(data, new Parameters(factory, dataMappers))
 {
 }

 protected override IList<IRule> CreateRules()
 {
 IList<IRule> ret=base.CreateRules();
 ret.Add(
 new PredicateRule<FindProductListByName>(
 "The name must not be empty.",
 new Predicate<FindProductListByName>(
 delegate(FindProductListByName s) {
 return !string.IsNullOrEmpty(s.Data.Name);
 }
 )
 )
 );

 return ret;
 }

 protected override void OnInitialized(ActivityStateEventArgs e)
 {
 Question=((Parameters)Parameters).QuestionFactory.AskProductName(e.Controller);
 base.OnInitialized(e);
 }

 protected override IActivityState NextState
 {
 get { return new FindProductListByNameFindProducts(Data, (Parameters)Parameters); }
 }
 }

 internal class FindProductListByNameFindProducts:
 ActivityState<Data>
 {
 public FindProductListByNameFindProducts(Data data, Parameters parameters) :
 base(data, parameters)
 {
 }

 protected override ActivityStateResult Handle(IActivityController controller)
 {
 List<Product> allProducts=new List<Product>(Product.FindAll(((Parameters)Parameters).DataMappers));
 Data.Products=allProducts.FindAll(
 new Predicate<Product>(
 delegate(Product p) {
 return p.Name.Contains(Data.Name);
 }
 )
 );

 return ActivityStateResult.Next;
 }

 protected override IActivityState NextState
 {
 get { return new EndActivityState<Data>(Data); }
 }
 }
}

Note in the question state how we enforced our business rule (the name must not be empty).

Our activity is ready. Or is it ? What we have here is still an abstraction, and we need an implementation for our QuestionFactory. And that is precisely the magic of it all : we just need a concrete QuestionFactory.

Say, for instance, that we want to test our activity : we need a question factory that automatically provides the Data with test product names and checks the results. Here is an implementation of this question factory :

internal sealed class TestQuestionFactory:
 QuestionFactory
{
 public TestQuestionFactory(string name)
 {
 _Name=name;
 }

 public override Question AskProductName(IActivityController controller)
 {
 Question ret=new AnsweredQuestion();
 ret.Answering+=new EventHandler<AnswerEventArgs>(
 delegate(object sender, AnswerEventArgs e) {
 ((Data)e.Data).Name=_Name;
 }
 );

 return ret;
 }

 private string _Name;
}

Based on this factory, a test would look like this (there are two products containing Queso in their name in the Northwind database) :

[TestMethod]
public void CanFindProductList()
{
 Data data=new Data();
 ActivityController controller=new ActivityController(
 new FindProductListByName(
 data,
 new TestQuestionFactory("Queso"),
 DataMappers
 )
 );
 controller.Execute();

 Assert.IsTrue(controller.HasCompleted);
 Assert.AreEqual(2, data.Products.Count);
}

You can see here how an ActivityController is used to execute an activity. As all answers are automatically provided, our activity is executed from the beginning to the end in one phase. In a Windows Forms application, the execution would stop at the question state to let the user fill a text box in. When a Find button would be clicked, the controller would be told to resume the activity execution.

You can find a complete working example, as a Visual Studio 2008 solution, here. The same activity is implemented as a unit test, and as a Windows Forms application (the underlying database is Northwind on SQL Server, for which a data file is included in the downloadable sample).

QuickStart : the Domain Model [The road to Salamanca]

Tue, 23 Sep 2008 07:32:00 -0700

Now that the first release is out, let's start playing with it. The first step is to design our business objects ; we'll eventually have a DSL for this (the SDML), but basic UML will do for now.

We'll begin with a (very) simple model. Sorry, I could not think of anything more simple ;-) Our application will deal with products, whose sole property is their name.

The associated database could be created with the following script :

CREATE TABLE Products (
 ProductID INT IDENTITY(1, 1) NOT NULL,
 ProductName VARCHAR(40) NOT NULL
 CONSTRAINT PRIMARY KEY (ProductID)
);

Now we can create our Data Access Layer. What we need first is a class to handle the primary key for our product. We have a base class for it, in the Salamanca.DataAccess namespace :

using System;
using Salamanca.DataAccess;

namespace QuickStart
{
 public class ProductPrimaryKey:
 PrimaryKey<int>
 {
 public ProductPrimaryKey():
 base()
 {
 }

 public ProductPrimaryKey(int key):
 base(key)
 {
 }

 public static implicit operator ProductPrimaryKey(int key)
 {
 return new ProductPrimaryKey(key);
 }

 public static explicit operator int(ProductPrimaryKey key)
 {
 return key.Value;
 }
 }
}

Then we need a class to be used as a data holder. More specifically, it will be used as a Data Transfer Object :

using System;
using Salamanca.DataAccess;

namespace QuickStart
{
 public class ProductDataTransfer:
 IDataTransferObject
 {
 public object Clone()
 {
 return MemberwiseClone();
 }

 public int Id;
 public string Name;
 }
}

What remains to be defined is our Domain Model and our Data Mapper. To avoid too tight coupling between both, we'll define an interface that will have to be implemented by a product related Data Mapper :

using System;
using Salamanca.DataAccess;
using Salamanca.DataAccess.Collections;

namespace QuickStart
{
 public interface IPersonMapper:
 IDataMapper
 {
 Product Find(ProductPrimaryKey key, DataMapperCollection dataMappers);
 DomainModelKeyedCollection<Product> FindAll(DataMapperCollection dataMappers);
 }
}

For a starter, we'll only need two methods :

one to get a specific product instance from the data backend.
one to get all the products form the data backend. The DomainModelKeyedCollection returned can be used a regular Collection, as well as a Dictionary where products are indexed with their primary keys.

Now we're ready to define our Domain Model :

using System;
using System.Collections.Generic;
using Salamanca.DataAccess;
using Salamanca.DataAccess.Collections;
using Salamanca.DataRules;


namespace QuickStart
{
 public class Product:
 DomainModel<ProductPrimaryKey, ProductDataTransfer>
 {

 public Product():
 base()
 {
 }

 public Product(DataMapperCollection dataMappers):
 base(dataMappers)
 {
 }

 protected override ProductPrimaryKey CreateId()
 {
 return new ProductPrimaryKey(Data.Id);
 }

 public static Product Find(ProductPrimaryKey key, DataMapperCollection dataMappers)
 {
 return ((IProductMapper)dataMappers[typeof(Product)]).Find(key, dataMappers);
 }

 public static IList<Product> FindAll(DataMapperCollection dataMappers)
 {
 return ((IProductMapper)dataMappers[typeof(Product)]).FindAll(dataMappers);
 }

 internal void SetId(int id)
 {
 Data.Id=id;
 }

 [StringLengthRule(40)]
 [NotNullRule]
 public string Name
 {
 get
 {
 Load(true);
 return Data.Name;
 }
 set
 {
 if (Data.Name!=value)
 {
 Data.Name=value;
 RaisePropertyChanged("Name");
 }
 }
 }
 }
}

As you can see, this is quite straightforward : just inherit from Salamanca.DataAccess.DomainModel, override CreateId and add your properties. The static methods have just been defined here for convenience. Also, note the attributes above the Name property, that define our first business rules.

Final step : define a Data Mapper for our product. We'll choose the ADO .NET based abstract implementation that is found in the Salamanca.DataAccess.Data namespace as a base :

using System;
using System.Collections.Generic;
using System.Data;
using System.Data.Common;
using Salamanca.DataAccess;
using Salamanca.DataAccess.Collections;
using Salamanca.DataAccess.Data;

namespace QuickStart
{
 public partial class ProductMapper:
 DataMapper<Product , ProductDataTransfer ProductPrimaryKey>,
 IProductMapper
 {
 public ProductMapper(DbConnection connection, ICacheManager cacheManager):
 base(connection, DomainModelCreator.CreateDefault<Product>(), cacheManager)
 {
 }
 
 public DomainModelKeyedCollection<Product> FindAll(DataMapperCollection dataMappers)
 {
 IDbCommand[] commands=new IDbCommand[1];
 
 commands[0]=Connection.CreateCommand();
 commands[0].CommandType=CommandType.Text;
 commands[0].CommandText="SELECT ProductID, ProductName FROM Products";
 
 return Load(commands, dataMappers);
 }
 
 protected override IList<IDbCommand> CreateSelectCommands(ProductPrimaryKey key)
 {
 IDbCommand[] commands=new IDbCommand[1];
 
 commands[0]=Connection.CreateCommand();
 commands[0].CommandType=CommandType.Text;
 commands[0].CommandText="SELECT ProductName FROM Products WHERE ProductID=@Id";

 IDbDataParameter p=commands[0].CreateParameter();
 p.ParameterName="@Id";
 p.DbType=DbType.Int32;
 p.Value=key.Value;
 p.Direction=ParameterDirection.Input;
 commands[0].Parameters.Add(p);
 
 return commands;
 }

 protected override IList<IDbCommand> CreateDeleteCommands(ProductDataTransfer data)
 {
 IDbCommand[] commands=new IDbCommand[1];
 
 commands[0]=Connection.CreateCommand();
 commands[0].CommandType=CommandType.Text;
 commands[0].CommandText="DELETE FROM Products WHERE ProductID=@Id";
 
 IDbDataParameter p=commands[0].CreateParameter();
 p.ParameterName="@Id";
 p.DbType=DbType.Int32;
 p.Value=data.Id;
 p.Direction=ParameterDirection.Input;
 commands[0].Parameters.Add(p);
 
 return commands;
 }

 protected override IList<IDbCommand> CreateInsertCommands(ProductDataTransfer data)
 {
 IDbCommand[] commands=new IDbCommand[1];
 
 commands[0]=Connection.CreateCommand();
 commands[0].CommandType=CommandType.Text;
 commands[0].CommandText="INSERT INTO Products (ProductName) VALUES(@ProductName)";
 
 IDbDataParameter p=commands[0].CreateParameter();
 p.ParameterName="@Name";
 p.DbType=DbType.String;
 p.Value=data.Name;
 p.Direction=ParameterDirection.Input;
 commands[0].Parameters.Add(p);
 
 return commands;
 }

 protected override IList<IDbCommand> CreateUpdateCommands(ProductDataTransfer data)
 {
 IDbCommand[] commands=new IDbCommand[1];
 
 commands[0]=Connection.CreateCommand();
 commands[0].CommandType=CommandType.Text;
 commands[0].CommandText="UPDATE Products SET ProductName=@Name WHERE ProductID=@Id";
 
 IDbDataParameter p=commands[0].CreateParameter();
 p.ParameterName="@Name";
 p.DbType=DbType.String;
 p.Value=data.Name;
 p.Direction=ParameterDirection.Input;
 commands[0].Parameters.Add(p);
 
 p=commands[0].CreateParameter();
 p.ParameterName="@Id";
 p.DbType=DbType.Int32;
 p.Value=data.Id;
 p.Direction=ParameterDirection.Input;
 commands[0].Parameters.Add(p);
 
 return commands;
 }

 protected override ProductDataTransfer GetDataTransferObject(IList<IDataRecord> records)
 {
 ProductDataTransfer data=new ProductDataTransfer();

 int ord=records[0].GetOrdinal("ProductID");
 if (!records[0].IsDBNull(ord))
 data.Id=records[0].GetInt32(ord);

 ord=records[0].GetOrdinal("ProductName");
 if (!records[0].IsDBNull(ord))
 data.Name=records[0].GetString(ord);
 
 return data;
 }
 
 protected override void OnInserted(Product domainModel, IList<IDbCommand> commands)
 {
 IDbCommand command=Connection.CreateCommand();
 command.CommandType=CommandType.Text;
 command.CommandText="SELECT @@IDENTITY";
 command.Transaction=commands[0].Transaction;
 
 domainModel.SetId(Convert.ToInt32(command.ExecuteScalar()));
 
 base.OnInserted(domainModel, commands);
 }
 }
}

That's it : derive from DataMapper and fill the gaps with pure ADO .NET code. You can already understand that this is where code generation will greatly improve the developer productivity.

Our Data Access Layer is now complete : we can build a simple application based on it. The only (?) tricky thing is that you will need to create an instance of DataMapperCollection. For our sample, simply use this code :

DataMapperCollection _DataMappers=new DataMapperCollection();
_DataMappers.Add(typeof(Product), new ProductMapper(Connection, new NoCacheManager()));

It creates a new collection based on a prexisting Connection, and our data is simply not cached in memory.

You can find a complete working example, as a Visual Studio 2008 solution, here. As you can see, we can build a simple application that integrates our Domain Model in a very few lines of code, with business rules validation (the underlying database is Northwind on SQL Server, for which a data file is included in the downloadable sample).

Next time, we will create our first activity. Stay tuned !

First public release [The road to Salamanca]

Tue, 16 Sep 2008 07:45:00 -0700

Today is the day when Salamanca hits its first public release, tagged 0.9.0. You can download it here.

This first release consists of the binaries for the three sets of libraries (Data Rules, Data Access and Data Activities), for the three following environments :

.NET Framework 2.0
.NET Framework 3.0
.NET Compact Framework 2.0

There is also (some) documentation with (some) sample code. Work on this matter is obviously still in progress, but you can find more complete sample code in the source code. Check for the Northwind projects, that are used for our unit tests, based on the Northwind sample database. They are quite complete at this stage and are used to demonstrate what generated code could look like.

The future looks bright, and there is a lot of very interesting work to be done (most of which has already been introduced in this blog). The following list is unordered and incomplete :

Migration to Visual Studio 2008, and .NET Framework 3.5 compatibility.
Unity integration.
LINQ integration.
JSON serialization.
ASP .NET AJAX integration.
WPF integration.
A Domain Model designer, an Activities designer, and related code generation, the whole thing being integrated into Visual Studio : a true and real Software Factory.

If you want to hit the road with us, you are more than welcome. For the time being, Salamanca has never been so close. Olé!

Inside the libraries (III) : Data Activities [The road to Salamanca]

Mon, 08 Sep 2008 08:47:00 -0700

Data Activities defines the base classes that help us implement our architectural pattern, centered around business activities. All the concepts developed in this context owe a lot to the vision and the ideas of Yves Darmaillac.

We define an activity as a part of a business process. All the business process parts that are involved in a business application define this application activities. An activity is a finite state machine, comprising two kinds of states :

treatment states : those require no external data (think user interaction). For instance, a treatment state can perform an action on our domain model (create a new reservation), or directly on the data (calculate booking fees). All a treatment state needs to perform its action is data.
question states : those do require external data. For instance, a question state can ask for data for a domain model instance (fill reservation details), or it can ask for a specific domain model instance (pick up your seat). Usually, a question is answered via user interaction (but not necessarily, like in the case of unit tests where answers can be automated).

The golden rule here is to make sure that all the application behavior is defined in terms of activities. Treatments are by definition self-sufficient and generic. Questions define abstractions that have to be implemented by the HMI layer. In effect, such abstractions can be implemented by all kinds of presentation technologies (console applications, Windows Forms, ASP .NET, WPF...) with no impact on the business logic.

The fundamental interfaces defined in this library are :

IActivityState is an interface implemented by an activity state, and treatment states in particular. IQuestionActivityState is a specialization that is implemented by a question state.
IActivityData is implemented by an activity data holder type : it holds the data that is manipulated by a specific activity.
IActivityParameters is implemented by an activity parameters holder type. An activity parameter could be seen as an immutable activity data.
IActivityController is implemented by an activity controller. Such a class is essential to the activity execution : it initiates the activity, terminates it and controls all the state transitions in between.

All the states must be validated before transition : this is achieved via the integration of Data Rules. The library defines base implementations for all these interfaces, and helpful classes to implement questions in specific presentation technologies (so far Windows Forms and ASP .NET).

Activities are at the core of our architecture : they manipulate data and act as a separation of concerns between the business logic and the presentation. In the future, we will be able to design our activities via our own DSL (SAML), and have base implementations (and best practices) for questions in other technologies such as WPF or ASP .NET AJAX.

I would like to finish with an analogy that might confuse some readers, but hopefully enlighten others : I like to think of a business activity as a RNA translation process, which is part of the protein biosynthesis. The elements involved in this process are :

a mRNA template. It holds the code for a specific protein. This code has a start and an end, and has to be followed in order. This is our finite state machine, each codon being seen as a state.
a ribosome. This is the protein "factory". It "reads" the codons one by one and performs an action on each of them : add the corresponding amino acid to the chain that will become our protein. This is our activity controller.
the protein. This is the result of the entire process. This could be seen as our data.

Inside the libraries (II) : Data Access [The road to Salamanca]

Mon, 01 Sep 2008 08:59:00 -0700

This one is simple : Data Access is an Object-Relational Mapping (ORM) library. As such, it owes a lot to the experience of NourY Solutions in the field of data management. But our ability to structure this experience and put it into words has been greatly enhanced by the remarkable work of Martin Fowler. Many concepts in use in this library are described in his book Patterns of Enterprise Application Architecture.

There are many .NET ORM libraries out there. As evoked before, we don't believe "one size fits all" applies when it comes to ORM ; the mismatch between the object world and the relational one is so huge that it can only be solved by specific solutions under specific sets of constraints. Data Access has been designed with these constraints in mind :

integration with Data Rules.
easy serialization of business object instances (XML for use in Web Services, JSON for Ajax applications...).
persistence backend abstraction : business objects should easily be persisted against any database backend, like a standard RDBMS solution (Sql Server, Oracle, SQLite...), or a web service, or even a flat file.
the developer always has to be in control : for instance, no on-the-fly SQL generation (though this could be added later as an option).
easy code generation (we want to build a Software Factory, after all !).

This library is organized around 4 interfaces :

IDomainModel : is implemented by a Domain Model. There is also an abstract class (DomainModel) that can be used as a base implementation for your business objects. It provides Data Rules implementation, serialization, and UI integration (through the implementation of the standard IDataErrorInfo, IEditableObject and INotifyPropertyChanged interfaces).
IDataMapper : is implemented by a Data Mapper, which basically provides the persistence backend abstraction. The library provides base implementation for persistence based on standard ADO .NET, Enterprise Library Data Access Application Block or Web Services.
IDataTransferObject : this interface is implemented by a Data Transfer Object. It is used to hold the data of a Domain Model, to transfer it between a Domain Model and a Data Mapper and to serialize our Domain Models.
IPrimaryKey : is implemented by custom Identity Fields types.

A DSL to design our Domain Models would look a lot like a class diagram. And it does actually ;-) (more on that later).

Our plans in the future for this library are :

Unity integration.
Ability to serialize trees of objects.
JSON serialization.
Powershell integration.
SSIS integration.

Next time will be the time to introduce Data Activities.

Inside the libraries (I) : Data Rules [The road to Salamanca]

Tue, 26 Aug 2008 06:27:00 -0700

Now is the time to delve a bit more into the libraries that lie at the core of our factory. On top of them lie Data Rules.

First of all, note that this library owes a lot to the work of Paul Stovell, and that most of the concepts discussed here can be found in this article of his.

So Data Rules is a validation framework. The goal here is to handle invalid data in your custom types a bit like DataSet does : instead of throwing an exception every time invalid data is affected to it, it records whether the data it is containing is valid or not; and if not, why. This allows for much smoother UI integration (that is what ErrorProvider and IDataErrorInfo are all about).

This library is organized around 2 interfaces :

IValidatable is here to help the developer define a custom type that has such a behavior. A validatable type is one for which any instance can be validated against a specified set of rules. In Data Access, our business objects are validatable : you can always know whether data is valid or not, and why. And if you try to persist an invalid business object, you will get an exception.
IRule is an interface implemented by a validation rule. A rule can be specific to a property of your custom type (is it null ?), or not (for rules that involve many properties for instance). The description of a rule contains a message that can be displayed to the end user (like "This field is required").

The library predefines a set of useful rules (like NotNullRule, StringLengthRule, RegexRule...). These rules can also be specified as attributes. And there is an adapter that allows to integrate the Enterprise Library Validation Application Block in Data Rules.

As previously stated, Data Rules is used by Data Access to add validation capability to our business objects. It is also used by Data Activities to enforce business rules in our data flow.

In the future, we can imagine to create our DSL to design our rules, and why not store some of them in a configuration file.

Next time, I will try to summarize the vast subject of Data Access.

Visiting Salamanca [The road to Salamanca]

Wed, 20 Aug 2008 08:31:00 -0700

Fundamentally, Salamanca is designed around three sets of libraries :

Data Access is the easiest to explain in a few words : think of it as (yet) an (other) Object-Relational Mapping (ORM) library. Why another ? We believe that there is not nor will ever be a perfect solution for this problem ; call us "ORM limitations acceptors". Our belief is that an ORM solution has to be designed to fulfill a specific set of issues under a specific set of constraints (which definitely sounds like a product line to me). After all, if you want to go around and around in circles without going anywhere, you are more likely to win the race with a formula one car. If you want to drive home, you will be better off with a standard commercial car : it has been designed for average roads, and priced accordingly. This library will help us handle business specific data in a Data Access Layer (DAL).
Data Activities is a library that helps define the business data lifecycle into a specific layer. The latter is a state machine which lies at the core of our architecture : it manages business data, drives the HMI, and as such acts as a perfect (?) separator of concerns.
Data Rules is a validation framework. It will be used to implement our business rules in our activities transitions and our data.

These libraries represent the fundamental abstractions around which our applications will be built. Best practices can be documented around their use, that can be written with our own Domain Specific Languages (DSLs). We have defined two DSLs so far :

SDML (Salamanca Domain Modeling Language) : this language will help us structure our data in order to implement our DAL. But more than that, it will help us create reusable states for our activities, or reusable component for data edition (user controls in Windows Forms for instance). Its representation is very close to a UML Class Diagram.
SAML (Salamanca Activities Modeling Language) : this will help us define our activities. Activities reuse concepts defined in a SDML model. Its representation is inspired by the Business Process Modeling Notation (BPMN).

Implementing an application with our libraries once the models are properly defined should be quite straightforward. So straightforward that we will be gain a lot by creating two tools that will greatly enhance our productivity :

A Modeler : a graphical tool that will help us visually model our application and serialize it in SDML and SAML formats.
A Generator : a tool that will implement our best practices and take our model as input, in SDML and SAML formats, and generate our C# code. Though it is imaginable to generate a whole functioning application, the developer will have the possibility to customize the generated code to make it more usable, or implement parts that could not be modeled. Usually, developers will ... develop a usable HMI on top of the generated code.

As for now, the libraries are quite in an advanced state, the DSLs definition is in progress and the tools are part of our to do list.

Getting on the tracks [The road to Salamanca]

Mon, 04 Aug 2008 11:35:00 -0700

So, if Salamanca is a software factory, what is the product line associated with it? The answer is simple : business applications.

Alright, I think I can be more specific than this. In our context

a business application is a software that handles business specific data while implementing parts of business specific processes (which we will call activities) and enforcing business specific rules.

There are a few things we can infer from this definition :

to handle business specific data, we will deal with a database backend ; more often than not a real RDBMS like Sql Server or Oracle, but also possibly a web service or even a simple file (XML, CSV...). For instance, a hotel room booking application would be built upon a proper database, with structured data such as the rooms, their rates, their vacancies...
the data lifecycle has to be integrated into well defined activities. At all times, from the state that we know the system is in, there are only a few well known actions that can be taken. Without this concept, an application like Excel would fit into our definition. For instance, a basic activity involving a hotel room and a customer would be : book, then check in, then check out.
rules must be enforced at all times. Some of them are specific only to some piece of data, some others can be also specific to a specific activity. For instance, a booking date in the system cannot be anterior to the date the hotel was built : this is a general rule. But for new reservations, the same booking date has to be in the future : this is a rule that applies to the same data, but that is specific to the activity called "book a room in the hotel".

Our vision with Salamanca is to be able to design a business application in terms of data, activities and rules and be able to generate a complete and functional (if not user-friendly) software.

But we also want to leave the developer at the center of our factory. There are many libraries and tools (think of code generators) out there in the field that work very well, provided you respect their predicates (data structure, software architecture...). But in real life, you almost always have to adapt your code to business specific conditions : already existing databases, specific procedures, architecture... Applications built with Salamanca must be open to adaptations by developers. Think only of the HMI : would you use a software exclusively designed by automated tools ? I know I would not.

Through the concept of activities, which I will elaborate on more in another post, we also created a new way to clearly separate the concerns of presentation from the core application, which we found to be very promising so far. Once created the core of your business application (data handling, activities and rules), you could develop your HMI layer in any (.NET related) technology you like : Windows Forms, Windows Presentation Foundation, ASP .NET... Or in all of them. Or, maybe wiser, you could develop part of your application as an ASP .NET application, and part of it as a Windows Forms application (on Windows TabletPC or Windows Mobile for instance), while reusing the same set of core libraries with your business specific data, activities and rules.

I really hope I made you want to know more about it. In future posts, I will talk about our libraries, our models and our tools. Stay tuned !

A first glimpse of Salamanca [The road to Salamanca]

Tue, 29 Jul 2008 03:30:05 -0700

Welcome to the team blog of Salamanca!

Salamanca is a business applications software factory. The goal is to enable developers to create business oriented applications in a more efficient, reliable and coherent way through a specific set of libraries, models and tools. To make it short, we define a business application as a software that handles business specific data (you can think of it as a low scale enterprise application). Salamanca is designed to help managing the whole life cycle of business data : storage, display, edition, validation, processing... More on that later.

Salamanca is an open-source project, hosted on CodePlex. Its name is a reference to The Salamanca, the first commercially successful locomotive built in 1812.

We are delighted to have you on board, and we hope we will have a pleasant trip together ;-)