Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Abonnements

Comment WAQS vous propose d’exprimer vos règles métier ? 2/13

Posts précédents sur WAQS :

WAQS : Introduction

Comment utiliser WAQS?

Comment WAQS vous propose d’exprimer vos règles métier ? 1/13

 

Les propriétés calculées

Lors de la génération du code côté serveur, WAQS a créé un répertoire Specifications.

Ce répertoire est l’emplacement par défaut des règles métiers. Cet emplacement pourra être modifié ou complété avec d’autres répertoires dans le fichier .waqs qui correspond la configuration de génération du code.

Comme évoqué plus haut, l’idée est d’écrire du code à part. Il ne sera donc pas possible d’utiliser une propriété sur les classes d’entités.

De fait, nous allons utiliser des méthodes statiques.

Afin d’homogénéiser le code écrit par les développeurs, WAQS se base sur des conventions pour l’écriture du code métier.

Dans le cas des propriétés calculées, elles devront commencer par « Get » et être des extension methods sur le type à étendre.

Commençons avec un exemple très simple : une propriété calculées qui fait l’agrégation du CompanyName avec le ContactName.

public static class NorthwindSpecifications
{
    public static string GetCustomerName(this Customer c)
    {
        return string.Concat(c.CompanyName, " - ", c.ContactName);
    }
}

Après une nouvelle génération des T4, nous avons maintenant une propriété CustomerName sur la classe Customer côté client dont le get intègre notre code :

public string CustomerName
{
    get
    {
        try
        {
            if (Specifications != null && Specifications.HasCustomerName)
                return Specifications.CustomerName;
            return string.Concat(this.CompanyName, " - ", this.ContactName);
        }
        catch (System.NullReferenceException)
        {
            return default (string);
        }
        catch (System.InvalidOperationException)
        {
            return default (string);
        }
    }
   
set
    {
        throw new System.InvalidOperationException();
    }

}

Je vous expliquerai dans un prochain post l’intérêt du try, du if et du set.

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Publié mercredi 18 décembre 2013 11:09 par Matthieu MEZIL

Commentaires

Pas de commentaires

Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01