Traduction▲
Cet article est la traduction la plus fidèle possible de l'article de Manuel Felicio, Architecting Silverlight LOB applications (Part 4) - Metadata and localization(1).
Architecturer des applications métier Silverlight - Métadonnées et localisation▲
La spécification des métadonnées pour nos entités est la partie la plus facile et c'est 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 de métadonnées telle que décrite dans l'exemple suivant :
[MetadataType(typeof(Customer.CustomerMetadata))]publicpartialclassCustomer{internalclassCustomerMetadata{[Display(ResourceType=typeof(Metadata),Name="MyApp_Customer_Number")]publicintNumber;[Display(ResourceType=typeof(Metadata),Name="CommonProperties_Email")]publicstringEmail;[Include]publicEntityCollection<Order>Orders;}}
[MetadataType(typeof(Employee.EmployeeMetadata))]publicpartialclassEmployee{internalclassEmployeeMetadata{[Display(ResourceType=typeof(Metadata),Name="CommonProperties_Name")][StringLength(128,ErrorMessageResourceType=typeof(Metadata),ErrorMessageResourceName="CommonErrors_StringLength")]publicstringName;[Display(ResourceType=typeof(Metadata),Name="CommonProperties_Email")]publicstringEmail;[Include]publicDepartment Department;}}
L'attribut DisplayAttribute est très utile, car il annote les propriétés avec des informations qui peuvent être consommées de différentes manières. Par exemple, lorsque vous utilisez votre entité dans une datagrid, les entêtes des cellules vont automatiquement chercher DisplayAttribute et extraire la chaîne localisée pour cette propriété. La même chose s'applique pour les labels dans une dataform et si vous voulez créer votre propre framework d'interface utilisateur, 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 propriétés communes comme Email. La même chose aurait pu être faite pour Number et Name, mais cela dépend vraiment de chaque cas.
Vous pouvez également placer les règles de validation sur vos propriétés 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. Le plus intéressant ici étant que ces règles seront également disponibles côté client. Le DomainService fait en sorte qu'avant l'exécution des opérations sur les entités, 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 soient effectuées après l'appel à la méthode ExecuteChangeSet du DomainService et juste avant la méthode PersistChangeSet.
Plus de détails sur la spécification des métadonnées peuvent être trouvés dans la documentation ou d'autres ressources sur la toile. Je veux simplement mettre l'accent sur un aspect différent sur lequel peu de gens ont tendance à écrire. C'est le partage des ressources entre le client et le serveur. Le projet client ne compilera pas si les métadonnées ResourceManager ne sont pas disponibles. Comme elles sont définies sur le serveur, vous devez suivre ces étapes afin de les activer sur le client :
- ajoutez les fichiers de ressources en tant que lien dans le projet client ;
- modifiez l'espace de noms par défaut de votre projet client au même espace de noms qui est défini dans le projet serveur qui contient les fichiers de ressources ;
- modifiez le .csproj du projet client là où il fait référence au fichier lié Designer.cs et ajoutez 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 dans le projet client que dans le projet serveur. Dans ce cas, j'ai créé un dossier Resources dans les deux projets.
- assurez-vous également 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 pour les fichiers dépendants, tels que Medatata.resx / Metadata.Designer.cs ne va pas automatiquement les marquer comme dépendants, 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.
Conclusion▲
Dans le prochain article, nous aborderons le développement client.
Liens▲
Pour terminer, je tenais à dire que tout le code est disponible sur http://code.google.com/p/mfelicio-wordpress sous trunk/2010/SL-MVVM-RIA.
Remerciements▲
Je tiens ici à remercier Manuel Felicio de m'avoir autorisé à traduire son article.
Je remercie tomlev pour sa relecture technique et ses propositions.
Je remercie également Bovino pour sa relecture orthographique et ses propositions.
