Cet article fait partie d'une série expliquant comment architecturer une application d'entreprise Silverlight centrée sur les données. Silverlight, lorsqu'elle est combinée avec les patterns les plus populaires aujourd'hui et certaines technologies-clés pour le génie logiciel, peut être une technologie très productive, simple, fiable et efficace pour construire ce genre d'application, et en même temps fournir une expérience utilisateur exceptionnelle.

Langage/Outil/Technologie : Silverlight 4.

Commentez ce tutoriel : Commentez

- Titre : Architecturer des applications métier Silverlight

- Auteurs : Manuel Felicio, Deepin Prayag

- Parution : 17 janvier 2013

- Mise à jour : 5 mars 2013

- Licence : Copyright © 2013 Manuel Felicio. CDATA[Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 € de dommages et intérêts. Droits de diffusion permanents accordés à Developpez LLC. Cette page est déposée à la SACD.

Sommaire

- Traduction

- Architecturer des applications métier Silverlight - Métadonnées et localisation

- Conclusion

- Liens

- Remerciements

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 :

1. [MetadataType(typeof(Customer.CustomerMetadata))]
2. public partial class Customer
3. {
4.     internal class CustomerMetadata
5.     {
6.         [Display(ResourceType = typeof(Metadata), Name = "MyApp_Customer_Number")]
7.         public int Number;
8.
9.         [Display(ResourceType = typeof(Metadata), Name = "CommonProperties_Email")]
10.         public string Email;
11.
12.         [Include]
13.         public EntityCollection<Order> Orders;
14.     }
15. }

1. [MetadataType(typeof(Employee.EmployeeMetadata))]
2. public partial class Employee
3. {
4.     internal class EmployeeMetadata
5.     {
6.         [Display(ResourceType = typeof(Metadata), Name = "CommonProperties_Name")]
7.         [StringLength(128, ErrorMessageResourceType = typeof(Metadata), ErrorMessageResourceName = "CommonErrors_StringLength")]
8.         public string Name;
9.
10.         [Display(ResourceType = typeof(Metadata), Name = "CommonProperties_Email")]
11.         public string Email;
12.
13.         [Include]
14.         public Department Department;
15.     }
16. }

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.

(1)Le blog de l'auteur et l'article en anglais ne sont plus accessibles depuis quelques semaines.
Retour à l'article

Architecturer des applications métier Silverlight

Partie 4 - Métadonnées et localisation

Auteurs

| Manuel Felicio | Deepin Prayag |