2010-08-22 21 views
1

Je me réveille ce matin à un problème!POCOs, DTOs et IDataErrorInfo

Dans tous mes composants, j'ai un ensemble de règles métier qui sont utilisées pour valider les DTO avant que des modifications ne soient validées dans le référentiel.

J'ai essayé de trouver la meilleure façon d'obtenir des erreurs de validation de retour à l'interface utilisateur et je suis tombé sur l'interface IDataErrorInfo. Fantastique! Cependant, l'implémentation de cette interface transformerait mon DTO en un POCO et en ferait un objet plus grand en termes d'utilisation de la mémoire. Pour l'instant, tous les contrôles utilisateur sont liés aux objets DTO actuels.

La transformation de mes DTO en POCO aurait-elle un impact sur les performances? Ou existe-t-il un meilleur moyen de renvoyer les messages de validation à l'interface utilisateur?

Répondre

0

MVVM. c'est-à-dire que vos DTO sont enveloppés dans des modèles de vue, qui sont liés à votre vue.

-5

J'ai essayé de trouver la meilleure façon d'obtenir des erreurs de validation de retour à l'interface utilisateur et je suis tombé sur l'interface de IDataErrorInfo. Fantastique!

Absolument. Comment se fait-il que vous ne sachiez pas ce que vous faites en premier lieu? IDataErrorInfo est entièrement documenté - pas quelque chose que vous devriez "rencontrer" (qui sonne accidentellement).

La mise en œuvre de cette interface transformerait mon DTO en POCO et rendre un objet plus grand en termes de utilisation de la mémoire. À l'heure actuelle, toutes les commandes utilisateur sont liées aux objets DTO actuels.

Un DTO n'a absolument rien à faire en ce qui concerne les erreurs internes - il ne devrait jamais avoir d'erreurs internes. Voir, DTO est "Objet de transfert de données", pas "Objet métier". Le DTO est ce que l'objet métier devrait générer pour l'envoyer à DataAccessLayer, et la raison pour laquelle il ne devrait pas y avoir de validation est que l'objet métier s'assure que seuls les objets VALIDES CREATE DTO sont créés.

BTW,

transformerait mon DTO en POCO

J'ai une autre découverte surprise pour vous -. Votre DTO est déjà un POCO. POCO est "Plain Old CLR Object", et je suppose que votre DTO sont établis en tant que classes .NET, alors - devinez quoi, surprise, ils sont déjà POCO. Ce que vous voulez dire (encore quelque chose à découvrir), c'est que cela transformerait vos DTO en BO.

Ou y a-t-il un meilleur moyen de renvoyer les messages de validation à l'interface utilisateur?

Non, il n'y en a pas. La meilleure façon d'envoyer des messages à l'interface utilisateur est par interfaces définies par interface utilisateur, et IDataErrorInfo est-ce.

Votre problème est que vous avez une confusion hugh sur:

  • Comment programmer une architecture multi niveaux et la construction d'une couche d'accès aux données standard
  • ne sais pas quoi que ce soit sur les termes que vous utilisez (voir votre problème savoir ce qu'est un DTO et ce qu'est POCO).
  • Mélangez ainsi vos responsabilités.

Voir les réponses à POCO vs DTO pour une explication de ce que vous mélangez réellement.

Retour sur la planche à dessin. En tant que développeur/architecte principal pour vous présenter les architectures multi-niveaux et lire la documentation .NET.

Le DTO ne doit pas traiter les problèmes DataTransfer.

+10

Tous les points valides. J'ai marqué cette réponse comme correcte en fonction du point que vous avez fait. Essayez de ne pas être une dickwad aussi abrasive la prochaine fois. –