Actuellement, j'utilise des classes générées dans le fichier .dbml et transmettant les données au contrôleur via une implémentation du modèle de référentiel. Ma question est la suivante, ai-je besoin de créer des classes qui sont essentiellement des clones des classes du .dbml sans linq-to-sql et sans certains indicateurs, ou l'ID pour avoir la bonne séparation de la logique du domaine?Utilisation de MVC3 avec DBML
Les clones dont vous parlez ont un nom: afficher les modèles. Et oui, vous devriez absolument utiliser des modèles de vue. Ils sont adaptés aux exigences spécifiques d'une vue donnée. Le contrôleur doit ensuite interroger le référentiel afin de récupérer certains modèles de domaine (classe Linq-To-Sql générée automatiquement, entités EF, ...) et les mapper à une classe de modèle de vue qui sera transmise à la vue. Voilà comment IMHO chaque application ASP.NET MVC correctement conçu devrait être conçu. Vous ne devez pas transmettre de modèles de domaine à une vue ni recevoir de modèles de domaine en tant que paramètres d'action à partir d'une vue. Afficher uniquement les modèles
Les modèles de vue ne sont pas des clones d'un modèle de domaine. Un modèle de vue peut être mappé à partir de plusieurs modèles de domaine, ou un modèle de domaine peut se diviser en plusieurs modèles de vue. De cette façon, les vues ont toute la flexibilité pour représenter les données indépendamment de la façon dont ces données ont été transportées dans les couches de gestion.