Premier contrat avec la WCF

Question

Cette question est davantage une sonde pour découvrir ce que les gens font dans la communauté, dans des situations pratiques, qu’une question spécifiquement ciblée. J'ai effectué des recherches assez générales à ce sujet et, bien que j'ai trouvé beaucoup de blogueurs qui préconisaient la conception de services d'abord contractuels et quelques commentaires les confirmant, je n'ai pas encore trouvé beaucoup d'informations pratiques sur la mise en œuvre de contrats d'abord avec WCF, les avantages et les inconvénients. de le faire dans un environnement réel, etc. J'ai récemment effectué des recherches approfondies sur la SOA, principalement dans les livres de Thomas Erl, et l'un des principaux concepts qu'il préconise est la conception selon le principe du contrat.

Mes questions sont les suivantes:

1. Comment abordez-vous la conception de services d'abord sous contrat avec .NET et WCF?
2. Existe-t-il d’autres outils que svcutil pouvant générer des contrats et des clients? (Tout ce qui s'intègre à VS serait idéal)
3. Quels professionnels du monde réel avez-vous rencontrés avec la conception «contrat d'abord» et wCF?
4. Quels inconvénients du monde réel avez-vous rencontré avec la conception d'abord contractuelle et la WCF?

L’outillage constitue l’un des problèmes majeurs du développement sur contrat. Svcutil est la seule chose que j'ai trouvée qui puisse générer un code de service à partir d'un contrat, et la sortie est plutôt médiocre. Son fichier unique contient une multitude d'attributs et d'artefacts de génération de code. Il doit en principe être régénéré et remplacé chaque fois que le contrat est mis à jour. Je préférerais une meilleure approche, de préférence quelque chose qui ne nécessite pas de régénérer. Je peux très bien créer manuellement le contrat côté service, en supposant que ce soit pratique dans un scénario réel.

EDIT:

Alors que WCSF a résolu mes besoins immédiats, découvrez les tampons de protocole et Service Factory sont deux outils fascinants qui, j'en suis sûr, vont m'aider à l'avenir.

Answer 1

WSCF fournit un outil avant tout contractuel avec intégration VS. Vérifiez-le. (gratuit)

À partir du 6 juillet, il existe une version binaire avec un programme d'installation.

Answer 2

J'utilise une approche contractuelle, généralement (mais pas toujours) en utilisant la même représentation de type à chaque extrémité.

En fait, pour utiliser WCF, vous n’avez pas besoin de mandataires spéciaux, etc. vous pouvez utiliser vos types .NET habituels aux deux extrémités et ne pas utiliser svcutil.exe du tout . Obtenir un service fonctionnel est aussi simple que d’ajouter le & Quot; ABC & Quot; dans le fichier de configuration, et en utilisant quelque chose comme:

public sealed class WcfClient<T> : System.ServiceModel.ClientBase<T>
    where T : class
{
    public T Service { get { return base.Channel; } }
}

Vous pouvez maintenant utiliser:

using(var client = new WcfClient<IMyService>()) {
    int i = client.Service.SomeMethod("abc");
}

et tout ce que vous avez sur le client (et le serveur) est votre IMyService interface.

Pour d’autres outils; Protobuf-net est une implémentation des " tampons de protocole de Google " API, qui possède un DSL pour décrire des données et des services dans un & Quot; contrat d'abord & Quot; (et portable / interopérable), par exemple (un fichier .proto):

message SearchRequest {
  required string query = 1;
  optional int32 page_number = 2;
  optional int32 result_per_page = 3;
}
message SearchResponse {
  repeated string result = 1; 
}
service SearchService {
  rpc Search (SearchRequest) returns (SearchResponse);
}

L'outil protobuf-net (que je maintiens) inclut un & "protogène &"; utilitaire pour transformer cette DSL en C # / VB; et l'une des options (pour C #, du moins - il faudrait que je vérifie VB) est d'émettre une implémentation complète du proxy WCF (avec votre choix de méthodes sync ou async); très similaire à svcutil - mais (en raison de la relation protobuf-net), il inclut l'attribut personnalisé [ProtoBehavior] sur les contrats d'opération de sorte qu'il utilise le sérialiseur protobuf-net au lieu de DataContractSerializer (plus rapide et plus efficace, mais différent ).

Pour l'intégration VS; J'y travaille exactement ( preuve ).

Answer 3

Je préfère le développement avant tout contrat. J'ai utilisé la Service Factory à cette fin. Cela m'a permis de générer le code du service et celui du client sans personnalisation.

Grâce à la personnalisation , nous avons également été en mesure de générer des objets de transfert de données correspondant aux objets Entity Framework, ainsi que le code permettant la conversion de l'un à l'autre. enregistrement automatique des exceptions; et documentation HTML des services.

Cela s’ajoute aux règles d’analyse de code fournies avec Service Factory, qui permettent d’empêcher un développeur de se tirer une balle dans le pied en choisissant des options WCF incompatibles.

Answer 4

Dans WCF, vous avez une certaine diversité dans ce à quoi ressemble le "contrat d’abord". Vous pouvez créer un «contrat de code en premier lieu» dans lequel vos contrats de données et de services sont exprimés sous forme de types .NET avec le bon balisage d'attribut. Vous pouvez commencer avec WSDL et générer les contrats de service et de données, ou le schéma XML de votre contrat de données et exprimer le contrat de service sous forme de code. La manière dont vous allez dépendre dépend vraiment de la nature du contrat et de la manière dont il sera utilisé.

Si vous implémentez quelque chose dans une spécification WSDL, le code généré par WSDL est le choix évident, et générer à partir de la main n’est pas si grave. Vous pouvez déclencher la génération à partir d'un événement de construction du projet (ou entrer dans msbuild) si vous souhaitez que les modifications apportées au fichier WSDL se propagent immédiatement.

Si vous avez un schéma existant (XSD) que vous souhaitez utiliser en tant que contrat de données ou préférez développer votre contrat de données de cette manière pour une réutilisation plus facile sur d'autres plates-formes, vous pouvez générer des types à partir de schéma à l'aide de xsd.exe ( ou une alternative tierce partie). Dans ce cas, vous utiliseriez vos types sérialisables XML dans votre contrat de service orienté code, comme this :.

Si vous développez vous-même les clients et les serveurs dans .NET et que vos clients peuvent obtenir vos assemblages de contrats ou sont heureux de générer des clients à partir de métadonnées de service (par exemple, WSDL), la modélisation de vos contrats dans le code est une expérience enrichissante. Utilisation des & Quot; types connus & Quot; vous pouvez prendre en charge les modèles d’héritage dans votre contrat de données, ce qui peut être très puissant. Vous pouvez ignorer entièrement la génération du code client (comme indiqué dans d'autres réponses) en faisant directement référence à l'assemblage du contrat dans votre client. C'est très productif et élégant, mais vous devez savoir que vous pouvez créer des défis d'interopérabilité si vous avez trop de fantaisie.

Answer 5

La façon dont nous procédons est décrite dans cette vidéo:

http://www.dnrtv.com/default.aspx?showNum=103

L'idée est que nous n'utilisons pas la génération de code, nous évitons donc d'avoir à régénérer le code lorsque le contrat est modifié.

Le contrat est alors dans le code et peut être modifié. En cas d'incompatibilité entre le client et le serveur, une erreur de génération apparaîtra.