Quelles bonnes pratiques WCF suivez-vous dans la conception de modèles objet ?

Question

J'ai remarqué qu'une poignée d'applications WCF choisissent de « briser » leurs objets ;autrement dit, un projet peut avoir un assembly DataObjects qui contient des DataContracts/Members en plus d'une bibliothèque de classes significative qui exécute la logique métier.

Est-ce un niveau d’abstraction inutile ?Existe-t-il un mal inhérent associé au fait de parcourir et de baliser les bibliothèques de classes existantes avec les informations DataContract ?

En passant, comment gérez-vous les conditions d’erreur ?Les exceptions levées par le service (InvalidOperation, ArgumentException, etc.) sont-elles généralement acceptées, ou existe-t-il généralement un niveau autour de cela ?

Answer 1

La principale raison pour laquelle vous devez séparer les objets métier internes des contrats de données/contrats de message est que vous ne souhaitez pas que les modifications internes apportées à votre application modifient nécessairement le contrat de service.Si vous créez des services Web versionnés (avec plus d'une version des interfaces implémentées), vous disposez souvent d'une seule version des objets métier de vos applications avec plus d'une version des objets de contrat de données/de message.

De plus, dans les situations complexes d'intégration d'entreprise, vous disposez souvent d'un format de données canonique (contrats de données et de messages) partagé par un certain nombre d'applications, ce qui oblige chaque application à mapper le format de données canonique à son modèle objet interne.

Si vous souhaitez un outil pour vous aider dans les détails de la séparation du contrat de données/du contrat de message, etc.puis consultez l'usine logicielle de services Web de Microsoft http://msdn.microsoft.com/en-us/library/cc487895.aspx qui contient de bonnes recettes pour résoudre le problème de plomberie WCF.

En ce qui concerne les exceptions, WCF encapsule automatiquement toutes les exceptions dans FaultExceptions, qui sont sérialisées sous forme de fautes au format filaire.

Il est également possible de lancer des exceptions de faute génériques qui vous permettent de spécifier des détails supplémentaires à inclure dans la faute sérialisée.Puisque les erreurs générées par une opération de service Web font partie de son contrat, c'est une bonne idée de déclarer les erreurs sur la déclaration d'opération :

[FaultContract(typeof(AuthenticationFault))]
[FaultContract(typeof(AuthorizationFault))]
StoreLocationResponse StoreLocation(StoreLocationRequest request);

Les types AuthenticationFault et AuthorizationFault représentent les détails supplémentaires à sérialiser et à envoyer via le réseau et peuvent être générés comme suit :

throw new FaultException<AuthenticationFault>(new AuthenticationFault());

Si vous voulez plus de détails, criez ;Je vis et respire ce genre de choses depuis si longtemps que je gagne presque ma vie en le faisant ;)