Architecture Silverlight LOB – Concepts et technologies (Partie 5)

La Spécification des métadonnées pour nos entités est la partie la plus facile et voici un bon endroit pour commencer la localisation de notre application.

La première des choses que nous avons à faire est de créer une classe buddy tel que c’est décrit dans l’exemple suivant:

[MetadataType(typeof(Customer.CustomerMetadata))]
public partial class Customer
{
    internal class CustomerMetadata
    {
        [Display(ResourceType = typeof(Metadata), Name = "MyApp_Customer_Number")]
        public int Number;
 
        [Display(ResourceType = typeof(Metadata), Name = "CommonProperties_Email")]
        public string Email;
 
        [Include]
        public EntityCollection<Order> Orders;
    }
}
[MetadataType(typeof(Employee.EmployeeMetadata))]
public partial class Employee
{
    internal class EmployeeMetadata
    {
        [Display(ResourceType = typeof(Metadata), Name = "CommonProperties_Name")]
        [StringLength(128, ErrorMessageResourceType = typeof(Metadata), ErrorMessageResourceName = "CommonErrors_StringLength")]
        public string Name;
 
        [Display(ResourceType = typeof(Metadata), Name = "CommonProperties_Email")]
        public string Email;
 
        [Include]
        public Department Department;
    }
}

L’attribut DisplayAttribute est très utile, car il annote les propriétés de votre information qui peut être consommé de différentes manières. Par exemple, lorsque vous utilisez votre entité dans un Datagrid, les en-têtes des cellules va automatiquement chercher pour DisplayAttributes et récupérer la chaîne localisée pour cette propriété. La même chose s’applique pour les labels dans un Dataform et si vous voulez créer votre propre UI framework, vous pouvez exploiter ce type d’annotation pour commencer la localisation de votre application. Remarquez comment j’ai réutilisé des noms de ressources pour les common properties comme l’email. La même chose aurait pu être fait pour le nom, mais cela dépend vraiment de chaque cas.

Vous pouvez placer les règles de validation sur vos propriétés et en utilisant des attributs comme StringLength, appliquer des expressions régulières ou même créer vos propres règles de validation personnalisées. La grande partie à ce sujet est que ces règles seront disponibles dans le client ainsi. Le DomainService fait en sorte que, avant l’exécution des opérations sur les entités de toutes les règles de validation sont appliquées. Notez que vous ne pouvez pas faire toutes sortes de validation sur vos entités en utilisant des métadonnées. Certaines validations peuvent nécessiter la connexion à une base de données, transactions, etc, et cette information n’est pas disponible dans ce type de contexte de validation. Je recommande que de telles validations soit effectuées après ExecuteChangeSet DomainService est invoquée et juste avant la méthode PersistChangeSet.

Plus de détails sur la spécification des métadonnées peuvent être trouvées dans la documentation ou autres ressources sur le web. Je veux simplement mettre l’accent sur ​​un aspect différent que peu de gens ont tendance à écrire. C’est le partage des ressources dans le client et le serveur. Le projet client ne compilera pas si les métadonnées ResourceManager n’est pas disponible. Comme il est défini sur le serveur, vous devez suivre ces étapes afin de l’activer sur le client:

■ Ajoutez les fichiers de ressources comme un lien dans le projet client
■ Renommez votre namespace par default dans votre projet client par le même nom que dans le namespace qui est défini dans le projet serveur qui contient les fichiers de ressources
■ Changer le .csproj du client où il fait référence au fichier lié Designer.cs et ajouter ces lignes de code.:

<Compile Include=”..\..\..\Server\Data\MyApp.Data\Resources\Metadata.Designer.cs”>
 
      <AutoGen>True</AutoGen>      <Link>Resources\Metadata.Designer.cs</Link>
 
      <DesignTime>True</DesignTime>
 
      <DependentUpon>Metadata.resx</DependentUpon>
 
</Compile>

■ Assurez-vous que les fichiers de ressources ont le même chemin relatif au projet client que dans le projet serveur. Dans ce cas, j’ai créé un dossier des ressources dans les deux projets.
■ Assurez-vous aussi que le fichier de ressources a marqué son modificateur d’accès comme public.

Ces étapes sont nécessaires car l’ajout de fichiers liés aux fichiers dépendants, comme Medatata.resx / Metadata.Designer.cs ne va pas les marquer comme dependant automatiquement, vous devez donc le faire manuellement.

Maintenant, vous devriez être en mesure de compiler votre application et commencer à tirer profit des métadonnées dans vos entités.

Suite : prochain poste

PS : cet article est une adaptation en français d’une suite d’articles par Manuel Felício

Kamel DJELLAL
Chef de projet
EDIS CONSULTING – GROUPE UBISIDE

http://www.ubiside.fr/

Laisser un commentaire