Est-il sensé d'avoir des ViewModels dans l'API Web?
Je commence à apprendre le webapi et je me retrouve à faire des choses qui ont du sens dans un projet MVC mais qui peuvent ne pas avoir de sens dans.
Normalement, dans un projet MVC, je crée des ViewModels et je les utilise comme paramètre ou je les renvoie avec la vue.
Puisqu'il n'y a pas de vues dans webapi, je suppose que cela n'a pas de sens d'avoir un ViewModel comme paramètre.
Je me demande peut-être si je devrais simplement avoir comme paramètre mes domaines EF (coder d'abord) et mettre des annotations de données dessus. Je mettrais normalement les annotations sur les propriétés du modèle de vue car j'aimais cela sur le domaine.
Cependant, ce qui m'empêche de le faire, c'est que je ne sais pas à 100% comment mon site MVC fonctionnerait.
Le site MVC crache-t-il simplement des vues simples, puis vous utilisez Jquery pour appeler votre webapi ou appelez-vous simplement des méthodes d'action MVC qui appellent directement les mêmes méthodes que Webapi appellerait?
Si c'est la deuxième façon, je place à nouveau les annotations de données sur mon modèle de vue, mais je mets les mêmes sur le domaine EF et les machines virtuelles et cela semble redondant.
Mis à part la terminologie, il est toujours utile de disposer de modèles de liaison. Techniquement, ils ne sont tout simplement plus des ViewModels, dans la mesure où vous avez raison, aucune vue n'est impliquée. Mais ils sont définitivement toujours utiles. Leur utilisation vous permet de tirer parti des attributs des propriétés de votre modèle et de les réutiliser dans votre API si nécessaire. Souvenez-vous également que si vous utilisez directement vos entités, WebAPI modélisera tous les paramètres qui leur correspondent par leur nom, même si vous ne le vouliez pas.
En outre, les modèles d'entité sont des représentations de vos données brutes, mais les modèles utilisés pour la liaison sont un contrat fixe que les demandes d'API doivent satisfaire pour réussir le traitement d'une demande. Les valeurs dans lesquelles, pourraient finir par s'étendre sur plusieurs modèles d'entité au moment où votre implémentation est terminée, et ne pas être conservées du tout dans un magasin de données.
Ma suggestion après beaucoup de temps à travailler avec ce 'choses' :
BindingModels pour la liaison de données (mvc ou api)
ViewModels pour les vues sur mvc (vous pouvez avoir des pages mvc dans votre api, donc c'est bien d'avoir une place pour ça, cela peut être de la documentation, une page d'introduction, peu importe. S'il n'y a pas de vue, alors vous pouvez avoir zéro ViewModels) Un avantage de ceci est que vous pouvez dans votre Views/web.config avoir la référence de l'espace de noms ViewModels et il ne sera pas pollué avec vos ressources api.
ResourceModel pour les ressources de l'API Web. Dans webapi, les ressources imbriquées sont également des ressources qui vont n'importe où dans une arborescence, ce qui n'est pas si courant sur mvc, donc les nommer ressources a beaucoup de sens.
Si vous souhaitez recevoir une ressource, vous pouvez utiliser votre modèle de ressource. N'oubliez pas que vous recevez la même chose que vous renvoyez.
Si vous souhaitez une liaison personnalisée pour l'entrée (ce devrait être votre scénario par défaut), vous avez vos modèles de liaison.
Si vous avez une vue mvc, à des fins d'administration, de documentation, utilisez vos ViewModels.
Si vous avez une page de formulaire sur mvc, vous pouvez également utiliser votre BindingModel sur le contrôleur POST. Pas besoin d'avoir un modèle différent pour une publication sur MVC ou WEBAPI. Particulièrement lorsque le modèle de reliure ou le formateur peut à la fois comprendre et mapper vers le même modèle de liaison à l'aide des mêmes annotations de données.
Parfois, vous souhaitez créer un modèle de liaison avec une ressource et des champs supplémentaires. L'héritage est votre ami.
Parfois, vous souhaitez créer un modèle de liaison avec plusieurs ressources et (éventuellement, des champs supplémentaires) des ressources en tant que propriétés sont vos amis.
Dans le monde MVC, vous pouvez également utiliser le concept de "ressource", mais il est beaucoup moins courant. Cela est utile lorsque vous avez MVC et Web Api sur le même projet.
Si vous avez besoin de commentaires supplémentaires sur un élément (comme la structure des dossiers, les espaces de noms, etc.), faites-le moi savoir. Je suis plus qu'heureux de partager mon expérience contre les pros.
Oh, et j'ai oublié, une stratégie de cartographie mérite d'être étudiée. Personnellement, je fais mes propres mappages, mais avoir cette logique en un seul endroit n'a pas de prix.
EDIT: exemple très naïf
ContactViewModel{
string Name {get;}
string LastName {get;}
List<Country> AvailableCountries {get;}
Country Country {get;}
bool IsAdmin {get;}
}
ContactBindingModel{
string Name {get;set;}
string LastName {get;set;}
int Country {get;set;}
}
ContactResourceModel{
string Name { get;set;}
string LastName {get;set;}
Country Country {get;set;}
string IsAdmin {get;}
}
Si vous essayez de construire un système basé sur REST alors la notion de ViewModel et View peut être très utile. Vous pouvez mapper assez étroitement la notion de ressource à ViewModel et la représentation à View.
Si vous vous arrêtez pour réfléchir un instant à ce à quoi ressemble une vue dans un site MVC. C'est un document HTML. Un document qui contient un tas d'informations sémantiques, titre, corps, sections, paragraphes, tableaux, etc. Il n'est pas censé contenir des informations de "style". C'est le travail du navigateur Web et du CSS. Les gens sont confus lorsqu'ils commencent à considérer le HTML comme une interface utilisateur. Ce n'est pas censé être l'interface utilisateur, c'est le contenu de l'interface utilisateur.
Les vues ne sont qu'une réalisation concrète du contenu du modèle de vue à l'aide d'un type de support pouvant être transféré via le fil. Le type de support dépend du client que vous essayez de satisfaire.
Nous travaillons actuellement sur un projet similaire qui utilise ASP.Net MVC et ASP.Net Web Api.
Nous utilisons ASP.Net MVC pour générer la structure globale de nos pages. Ensuite, notre implémentation javascript MVVM appelle l'API Web pour remplir les données renvoyées dans les modèles de vue client. Pour ce faire, notre API renvoie un modèle de vue qui correspond à ce que le frontal attend.
Je pense que vos modèles de vue api seraient différents de MVC ViewModels (qui ne sont pas des ViewModels du point de vue MVVM).
Cela dépend aussi de votre utilisation de l'API. Par exemple, pour un usage interne, vous n'avez pas toujours besoin d'éviter d'afficher votre modèle de domaine. Vous éviterez ainsi de mapper le modèle dans le ViewModel et d'augmenter les performances. Mais dans le cas où vous avez besoin de transformer certaines propriétés dans vos modèles, viewModels vous aidera grandement à structurer votre code de manière peu couplée.
Puisqu'il n'y a pas de vues dans webapi, je suppose que cela n'a pas de sens d'avoir un ViewModel comme paramètre.
Je dirais que votre API est consommée par vos vues à la fin, il est logique d'avoir ViewModel.
Le site MVC crache-t-il simplement des vues simples, puis vous utilisez Jquery pour appeler votre webapi ou appelez-vous simplement des méthodes d'action MVC qui appellent directement les mêmes méthodes que Webapi appellerait?
C'est juste une question de choix ici. Vous pouvez appeler l'action MVC pour recevoir les vues générées (en html) ou vous pouvez appeler WebApi pour recevoir les réponses JSON/XML que vous lierez ensuite avec votre code javascript dans vos vues.
Juste pour ajouter ce que d'autres ont dit, l'utilisation de ce qui serait normalement appelé un ViewModel est également utile pour la validation. Vous pouvez baliser vos classes avec des annotations de données, y compris les exigences de validation. Dans vos actions de contrôleur, vous pouvez toujours utiliser ModelState pour forcer la validation à se produire et renvoyer les messages appropriés via HttpRequestException ou simplement HttpResponseMessage.