ASP.NET MVC vs WCF pour l'utilisation de l'API REST + de la page Web

Je pense que la discussion sur l'utilisation orientée service programmatique vs l'interaction humaine est claire.

Mais si je devais créer une application qui utilise à la fois une API de programmation et un site Web qui utilise les données connectées par la même API, est-ce que cela favoriserait l'utilisation uniquement d'ASP.NET?

Est-il facile d'intégrer ASP.NET et WCF pour travailler sur la même application?

— Xster
source

En ce qui concerne l'écriture d'une application qui exploite à la fois ASP.NET/MVC et WCF, ce n'est pas génial. WebAPI a peut-être amélioré les choses, mais dans un projet que je connais qui utilisait WCF et MVC dans la même application, ils ont fini par maintenir deux ensembles de modèles différents pour représenter les mêmes concepts - un pour le code WCF et un pour le MVC code. Vous pouvez imaginer tous les mappeurs qu'ils ont dû écrire pour traduire les choses entre les deux modèles - il y avait beaucoup de lignes de code qui auraient pu / auraient dû être évitées.

Cela est en partie dû au fait que les objets de demande et de réponse WCF doivent être annotés avec [DataContract] et leurs propriétés avec [DataMember], tandis que MVC ne l'exige pas. Idiomatic MVC, d'autre part, va vouloir ViewModels, qui ont des objectifs différents de WCF DataContracts. Bien sûr, il est possible que l'utilisation de deux ensembles complets d'objets de domaine ait plus à voir avec la loi de Conway de que les conflits WCF et MVC, mais il convient de souligner que WCF et MVC ont des objectifs et des exigences différents en ce qui concerne la sortie et l'entrée.

Personnellement, je suis partisan du développement d'une API back-end simple mais puissante orientée services, en particulier lorsque vous souhaitez plusieurs clients. Je pense que l'arrivée d'excellents cadres JavaScript MVVM et micro-MVC en fait un choix naturel, car l'écriture de code d'application à l'aide de BackboneJS , KnockoutJS et d'autres permet un environnement de développement performant. Vous pouvez ensuite consommer le back-end dans le micro MVC de votre choix pour créer votre application web, ou sur un client mobile, et vos partenaires peuvent également consommer la même API à distance.

Suggestion

WebAPI ou Service Stack peuvent être de bons candidats pour créer votre API principale. Je recommande Service Stack, car je l'utilise depuis quelques mois et je l'ai trouvé comme un excellent remplacement de WCF. J'écris actuellement une série de tutoriels sur la pile de services sur mon blog .

Le groupe qui gère la pile de services a publié un exemple d'application utilisant le cadre pour développer un clone de type StackOverflow qui montre un modèle de développement qui, à mon avis, est particulièrement convaincant. Cela implique un back-end de services basé sur un modèle simple que vous pourriez imaginer être consommé par un site Web MVC, une application mobile ou tout autre chose facilement. Les objectifs de conception de ServiceStack encouragent clairement un modèle qui devrait conduire à moins de couplage entre le client et le serveur. L'idée est d'éviter les API bavardes avec des appels comme GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm)en faveur de moins de méthodes. Vous pouvez implémenter la même chose dans la pile de services comme ceci:

[Route("/customers", "GET"]
[Route("/customers/search/{SearchTerm}", "GET"]
[Route("/customers/region/{Region}", "GET"]
[Route("/customers/region/{Region}/search/{SearchTerm}", "GET"]
public class Customers 
{
    public int? RegionId { get; set; }
    public string SearchTerm { get; set; }
}

public class CustomersService : Service
{
    public object Get(Customers request) {
        // handle request
        return new CustomersResponse();
    }
}

L'avantage, à mes yeux, est qu'au lieu d'avoir votre propagation de la logique métier au - dessus des tas de méthodes distinctes GetCustomersInRegionWithSearchTerm(int regionId, string searchTerm), GetCustomersInRegion(int regionId), GetCustomersWithSearchTerm(string searchTerm),GetCustomers() , il est en un seul endroit. Cela devrait conduire à un code plus maintenable.

Par coïncidence, Stack Exchange a embauché l' auteur d' origine de Service Stack . Il continue de s'engager activement dans le projet Service Stack.

J'aime particulièrement les files d'attente de messages pour certaines choses - et bien que WCF le permette, WebAPI ne le fait pas. ServiceStack autorise le même service Web à être appelé via MQ. Pour plus d'informations à ce sujet, consultez l'hôte Redis MQ sur: github.com/ServiceStack/ServiceStack/wiki/Messaging-and-redis

— Kyle Hodgson
source

Remarque: ServiceStack permet que le même service Web puisse être appelé via MQ, consultez l'hôte Redis MQ à l' adresse

— mythz

Excellent merci @mythz! Je ne le savais pas.

— Kyle Hodgson

mais il semble que mvc4 emprunte la voie de l'api web ... cela ne fait-il pas du framework "officiellement sponsorisé"?

— Xster

Après avoir lutté avec le "framework officiellement sponsorisé" (WCF pre WebAPI) pendant les deux dernières années, cela ne fait plus partie de mes critères de sélection. Cela ne veut pas dire que WebAPI est bon ou mauvais, je ne l'ai pas encore essayé. Je n'ai ressenti aucun désir, ServiceStack résout mes problèmes.

— Kyle Hodgson

Énoncer l'évidence ici, mais les ViewModels et les objets de réponse des services WCF sont deux choses complètement distinctes. Un ViewModel peut être uniquement un sous-ensemble de données ou des éléments de données provenant de différentes sources combinées. Avoir un ensemble d'objets différent pour ViewModels est exactement ce qui est nécessaire pour MVC, d'où les données proviennent (WCF ou autre) n'a pas d'importance. En outre, il existe Automapper pour le mappage entre les types d'objets pour enregistrer tout ce code passe-partout X.Name = Y.Name.

— ozz

@tzerb a répondu correctement IMO mais je voulais étendre cette réponse. L'API Web ASP.NET qui est actuellement en phase bêta et un projet OSS est le framework le plus proche que vous recherchez.

La courte description du produit est la suivante (citée sur la page de l' API Web ASP.NET ):

L'API Web ASP.NET est un cadre qui facilite la création de services HTTP qui atteignent un large éventail de clients, y compris les navigateurs et les appareils mobiles. L'API Web ASP.NET est une plate-forme idéale pour créer des applications RESTful sur le .NET Framework.

Quant à l'application client que vous utilisez peut-être pour consommer votre API Web, elle ne doit certainement pas être une application ASP.NET. Vous pouvez consommer votre API avec une page HTML statique en utilisant JavaScript. Vous pouvez le faire facilement avec certaines bibliothèques JavaScript utiles telles que jQuery.

D'un autre côté, vous pouvez certainement consommer votre API sur le site du serveur dans n'importe quelle application ASP.NET. Le projet d'API Web a également introduit une nouvelle API client HTTP .NET appelée HttpClient qui facilite la consommation de services HTTP.

En général, voici un bon ensemble de ressources pour commencer:

Prise en main de l'API Web ASP.NET - Tutoriels, vidéos, exemples

N'oubliez pas que le projet est encore dans sa phase bêta. Je vous recommande de suivre le blog Henrik F Nielsen où il publie des informations sur les dernières mises à jour non publiées du projet. Vous pouvez atteindre le code source du projet et le flux de développement dans le projet ASP.NET Web Stack .

— tugberk
source

Je pense que la preuve actuelle est d'utiliser l'API Web MVC au lieu de WCF pour REST. http://stephenwalther.com/blog/archive/2012/03/05/introduction-to-the-asp-net-web-api.aspx

Le modèle de développement est assez proche et vous contournez la configuration parfois méchante de WCF.

— tzerb
source