2010-12-13 74 views
1

Je développe une application Web ASP.NET (C# .NET 4) dans un scénario où je dois consommer WCF Services SOAP (VB.NET 4) fourni par un autre développement équipe comme le modèle.Utilisation des services Web SOAP comme modèle dans ASP.NET MVC

Les services sont hébergés sur IIS à l'aide d'AppFabric. La mise en œuvre WCF est créé pour soutenir le scénario suivant:

Une couche de service de données partagées qui est la langue/plate-forme indépendante. Une exigence est également que les services devraient fournir une boîte noire lorsque le développement frontal est sous-traité à des développeurs externes. Les services SOAP WCF sont utilisés pour fournir l'API Web commune. Les consommateurs des services sont à la fois des applications Web et des logiciels de bureau internes et externes.

Ma question concerne mon architecture d'application web actuelle. L'application est développée en utilisant ASP.NET MVC 2 et jQuery UI. D'après ce que j'ai lu jusqu'ici, il semble que l'utilisation de WCF SOAP Services comme modèle est acceptable. Mon plan est d'utiliser ViewModels et AutoMapper basé sur ce post:

Using SOAP web service object as a model in ASP.NET MVC 2

Quels sont les pièges le cas échéant?
Comment devrais-je développer la communication avec les services? Y a-t-il des frais généraux en termes de communication avec ce type d'architecture? Toutes les meilleures pratiques?

(Re-ingénierie de la couche de service à OData est pas une option à ce stade)

+0

Aucun piège. Du blogo et de la stackosphere, c'est à peu près comme ça que tout le monde le fait. – jfar

Répondre

1

Si vous pensez à vos services Web comme une « base de données distante » vous pouvez simplement suivre les mêmes pratiques que vous lors de l'élaboration une application MVC contre une base de données. Mais soyez prêt pour des problèmes de déconnexion beaucoup plus que vous auriez autrement. Je vous suggère de créer votre modèle pour encapsuler les appels aux services Web et fournir toute la logique de gestion des erreurs dont vous aurez besoin (ce qui sera probablement beaucoup si les services Web seront distants.) Rappelez-vous que la connectivité réseau sur un WAN n'est pas garanti et les hoquets ne sont pas inhabituels.