Dans ma candidature, je fais un appel de service et récupérez l'objet du contrat de données WCF peuplé. Je dois afficher ces données dans une grille. Est-il une bonne pratique de lier le contrat de données à la grille?
josh
3 Réponses :
En supposant que tous vos DTO soient amicaux pour la liaison de données, il ne faut pas avoir de problème à lier votre WCF DTOS à une grille.
Certains scénarios où vous ne voudrez peut-être pas se lier directement à vos DTO sont les suivants:
Vos DTO ne sont pas faciles à lier avec leur définition actuelle (E.G. Objets / Propriétés imbriquées)
Vous devez prendre en charge la notification des modifications apportées au client de liaison (généralement effectuée à l'aide de Vous souhaitez isoler votre code d'interface utilisateur des modifications apportées à la WCF DTO. Cela pourrait être dû au fait que vous ne contrôlez pas la définition du DTO ou que vous vous attendez à des modifications fréquentes dans les définitions DTO et que vous ne souhaitez pas modifier fréquemment votre code d'interface utilisateur. Bien sûr, si la DTO change alors, vous devrez modifier le code, mais vous pouvez isoler ces modifications à une petite couche de traduction.
inotifyPropertychanged )
Merci Slugster et Tuzo. Votre réponse aide beaucoup ... :)
est-il une bonne pratique de lier le contrat de données à la grille?
Oui. Il n'y a rien de mal à ce que vous faites.
Permettez-moi d'élaborer: ce que vous avez reçu du service WCF est un objet standard (parfois appelé dto -
dtt RansferO bject). Vous avez pas reçu un Datacontract - vous avez reçu un objet queutilisé A Datacontract pour contrôler le processus de sérialisation entre le service WCF et votre client. Le Datacontract peut contrôler ou dicter ce que vous obtenez, mais une fois que vous avez cet objet, vous êtes libre de le traiter comme vous le souhaitez.
Merci d'avoir défini une distinction claire en ce qui concerne le contrat de données WCF et les DTO.
Je recommanderais l'utilisation de modèles d'affichage pour toute liaison de données ou affichage de données (MVVM) sur le côté serveur (I.E. MVC) et le côté client (JavasCrip) Rendu.
Le principal risque d'utiliser DTOS renvoyé par le domaine est que si les DTO sont refactionnés pour une raison quelconque (c.-à-d. Les propriétés sont renommées, extraites dans d'autres objets ou d'autres objets sont fusionnés dans une seule) L'interface utilisateur va briser et nécessitera une mise à jour.
DTO est le contrat de ce qui est retourné par votre domaine, alors que les modèles de vue sont le contrat de ce que l'interface utilisateur exige. Les deux sont contrôlés par différentes exigences et, bien que ces exigences puissent être appliquées sur le même ensemble d'objets, le résultat est généralement un mélange ce qui est juste mal, sans oublier que les exigences que ne s'appliquent qu'à l'interface utilisateur ou de domaine déclenchera des changements dans l'autre partie. .
I.e. Les points de vue nécessitent souvent des données de plus de DTO ou de vues différentes nécessitent un sous-ensemble différent de données provenant du même Dto et dans les deux cas, le DTO ne devrait pas changer uniquement pour accueillir une vue concrète.
Il est également plus facile d'identifier quelles sont les exigences d'une vue si les vues ont un modèle de vue, plutôt que d'avoir le même DPO transmis à plus de vues.
John, j'apprécie votre réponse rapide. Je suis capable d'afficher les données avec succès dans la grille en contraignant le contrat de données. Mais ma question est que ma question est une bonne pratique de conception de lier l'interface utilisateur au contrat de données? Ou devrais-je créer un autre objet de domaine à partir du contrat de données et lier la grille à cet objet de domaine au lieu du contrat de données. Je n'aime pas la création d'un objet en double dans la mémoire. Laisse moi savoir ce que tu penses.