ASP.NET MVC - Modèle Linq to Entities comme ViewModel - est-ce une bonne pratique?

Question

Questions rapides vraiment.

Je suis actuellement en train de construire un site utilisant asp.net MVC et le framework d'entité. J'ai quelques référentiels en place qui renvoient des entités ou des listes d'entités. Je constate que dans la majorité de mes pages, je dois extraire des données de diverses tables connexes. C'est correct tant que je charge les entités liées en utilisant 'include' dans mes requêtes - mais est-ce une bonne pratique? Serait-il préférable de créer un objet viewmodel personnalisé qui contient juste les informations dont j'ai besoin, ou est-ce qu'il n'y a rien de mal à tirer un graphe d'objet qui est peut-être 5 - 6 tables juste pour afficher ce dont vous avez besoin à votre avis? Excuse si cette question n'a pas beaucoup de sens.

Je peux avoir fondamentalement mal compris comment un modèle doit être utilisé ici :)

Merci

Answer 1

Je suggère la révision du code de rendu dans vos vues et le code d'affichage dans vos contrôleurs. Sont-ils rendus trop complexes par l'approche que vous prenez? Sinon, vous êtes probablement autorisé à garder les choses telles qu'elles sont. Si le code de la vue et du contrôleur est grandement simplifié en introduisant un modèle de vue personnalisé, envisagez d'en créer un. Les modèles de vue personnalisés résument essentiellement une partie de cette complexité qui est probablement traitée ailleurs à l'heure actuelle.

Answer 2

Si vos vues commencent à faire des choses comme

<% foreach (var order in Model.Orders.Any(x => x.Products.Any(p => p.Category == "xx")) %>

alors vous avez certainement ViewModel. Vous pouvez aller avec

ViewData["flattened_orders"]

si vous préférez cordes magiques, mais je doute ainsi. Puis, il y a une question sur les attributs de présentation nécessaires sur vos entités, vous devez ensuite exposer toutes les propriétés pour que le classeur puisse fonctionner ... alors vous avez besoin d'autres informations de présentation comme la liste des pays ... Ainsi, pour les applications simples, vous pouvez ignorer ViewModel. Mais pour des applications simples, vous pouvez faire Response.Write et SQL manuel, de toute façon ;-)

J'aime vraiment this après un problème similaire. L'approche représentée ici peut sembler trop "académique" au premier abord, mais c'est de vrais projets, et plus je fais ASP.NET MVC, plus je l'aime et me rapproche d'elle.