WCF et Inheritance

Question

Je travaille sur un projet où j'ai une classe abstraite de rendez-vous. Il y a des entraînements, des repas et des mesures qui découlent tous du rendez-vous. Mon architecture ressemble à ceci jusqu'à présent:

Dao - avec des classes droit cadre d'entité couche d'accès aux données 4 maintenant POCO en utilisant les modèles T4 WCF Silverlight client, ASP.net MVP, les clients mobiles

Est-ce que je mettre des règles d'affaires dans la classe POCO? ou mappez mes entités à un objet métier avec des règles, puis mappez celles-ci aux objets DTO et transmettez-les via WCF? et quand je passe les DTO, est-ce que je passe par type rendez-vous? Ou écrire une méthode de service pour chaque sous-classe comme Workout ou Meal?

Je n'ai trouvé aucun bon matériel utilisant l'héritage de table par type et WCF.

merci d'avance!

-ajax

Answer 1

dépend principalement de la complexité dont vous avez besoin. Vous utilisez des classes POCO c'est un bon point de départ. Vous devez maintenant choisir la complexité de l'application que vous allez construire, la quantité de logique métier que vous voulez ajouter et que voulez-vous exposer à vos clients? L'entité POCO peut être simplement DTO ou vous pouvez transformer l'entité POCO en objet métier en ajoutant des méthodes métier et des règles directement dans cette entité - vous allez transformer l'entité en modèle d'enregistrement actif ou en objet Domaine. Je ne vois aucune raison de mapper vos POCO à un autre ensemble d'objets de gestion. L'exposition de l'entité POCO dans le service WCF est la méthode la plus simple. Vous pouvez utiliser des opérations qui fonctionneront directement avec la classe Appointment. De plus, vous devez donner à votre service des informations sur toutes les classes dérivées de Rendez-vous - cochez KnownTypeAttribute et ServiceKnownTypeAttribute. Utiliser l'entité signifie souvent que les appels de service transportent plus que nécessaire, ce qui peut poser problème aux clients mobiles qui ont une connexion Internet lente. Il y a un point spécial que vous devez connaître lorsque vous exposez une entité qui est la racine d'agrégation (contient des références à d'autres entités et une collection d'entités) - si vous n'avez pas le contrôle total sur les applications clientes vous devez valider non seulement chaque entité, mais aussi que ce client n'a changé que ce qu'il était autorisé à faire. Exemple: Supposons que le client souhaite modifier l'entité Order. Vous lui envoyez une commande avec toutes les entités OrderItem et chaque article aura une référence à son entité produit = graphe d'objets complets. Que se passe-t-il si, au lieu de modifier Order and OrderItems, le client modifie un produit (par exemple le prix)? Si vous ne le vérifiez pas dans votre logique métier exposée par WCF et transmettez le graphique d'objet modifié dans le contexte EF, il modifiera le prix dans votre base de données.

Si vous décidez d'utiliser vos entités comme des objets métier, vous n'exposez généralement pas ces entités, mais vous créerez un grand nombre de DTO. Chaque opération fonctionnera avec le DTO défini avec précision pour la demande et la réponse. Ce DTO ne transportera que les informations réellement nécessaires - cela réduira la charge utile des données pour les appels de service et évitera de répercuter les prix modifiés du produit, car vous définirez simplement votre DTO pour ne pas transférer le prix ou même le produit entier du client. Cette solution prend beaucoup plus de temps à mettre en œuvre et ajoute une couche supplémentaire de complexité. Parce que j'ai mentionné les graphes d'objets, je dois préciser qu'il y a un autre niveau de complexité caché quand on les utilise: le suivi des changements. Le contexte EF doit savoir ce qui a changé dans le graphe d'objet (au moins quel OrderItem a été modifié, qui a été ajouté ou supprimé, etc.) pour la persistance correcte. Le suivi et la solution à plusieurs niveaux est un problème. La solution la plus simple ne suit pas les modifications et utilise à la place une requête supplémentaire pour EF.Cette requête renvoie le graphe de l'état de l'objet persistant réel et le graphe de l'objet modifié est fusionné avec celui-ci (un soin particulier est requis pour les vérifications de simultanéité). D'autres solutions utilisent un support de suivi dans l'entité - vérifiez Tracking changes in POCO et Self-tracking entities. Mais ceci est seulement pour les entités. Si vous voulez suivre les changements dans DTO vous devez implémenter votre propre suivi des modifications. Vous pouvez également lire des articles du magazine MSDN sur les applications multi-niveaux et EF: Anti-Patterns To Avoid In N-Tier Applications; Building N-Tier Apps with EF4