Dans MVC, 1 modèle 1 tables ou 1 modèle plusieurs tables?Dans MVC, 1 modèle 1 tables ou 1 modèle plusieurs tables?
Je construis une application qui contient 3 tables. Je ne sais pas si je devrais créer un modèle pour les 3 tables ou créer 3 modèles pour 3 tables.
Dans le cas où j'utilise 3 modèles pour 3 tables, où devrais-je mettre le code si je veux joindre ces 3 tables? Mettez le code dans l'un des 3 modèles?
Des suggestions?
Habituellement, vous allez créer un modèle par table, donc dans votre cas, cela signifie que vous avez besoin de 3 modèles. Quand je dis «Modèle», je veux dire une classe qui représentera une seule rangée (habituellement) dans une seule table.
par exemple: Tables:
dans ce cas, le plus facile et simple est de créer 3 classes différentes (qui représente les données modèle de l'application) où la première classe représente un seul produit le suivant représente un ordre et la dernière classe représentera un seul client.
En général, la partie 'Modèle' de MVC doit être interprétée comme un 'modèle de présentation' ou un 'modèle de vue', c'est-à-dire une classe qui encapsule toutes les données et le comportement requis par la vue. Cela peut ou peut ne pas être équivalent au modèle de domaine.
Les modèles de domaine doivent être conçus pour être indépendants de l'interface utilisateur. Cela signifie que ces modèles ne doivent pas être pollués avec des données et un comportement spécifiques à l'interface utilisateur, par exemple pour déterminer si un bouton particulier est activé ou non. Vous pouvez également afficher les mêmes objets de domaine dans plusieurs vues différentes (par exemple, Maître/Détail ou Affichage/Edition), et si ces vues diffèrent suffisamment, disposer d'un modèle de vue pour chaque vue sera bénéfique. Donc, en général, vous devriez concevoir votre couche de domaine et votre couche de présentation de façon indépendante.
Dans la couche Domaine, vous pouvez choisir de modéliser vos trois tables en trois classes. Des livres tels que Patterns of Enterprise Application Architecture de Fowler et Domain-Driven Design d'Evans contiennent de nombreux conseils sur la modélisation de données relationnelles en tant que modèles de domaine.
Lorsqu'il s'agit de modéliser les vues dans MVC, il est plus logique de créer un modèle par vue. Un tel modèle de vue peut simplement encapsuler un seul objet de domaine, mais il peut également encapsuler et agréger plusieurs objets de domaine différents. De cette façon, vous pouvez assurer la séparation des préoccupations, et que vos classes suivent le principe de responsabilité unique. Pour des scénarios très simples, il peut être judicieux de réduire le modèle de domaine et le modèle de présentation en une seule couche, mais vous devez comprendre que cela signifie essentiellement qu'il n'y a pas de modèle de domaine dans la solution. .
Je suis désolé, je sais que c'est un vieux post.Après avoir lu votre message, j'ai fait des recherches sur les différents types de modèles et il me reste Vous avez dit qu'il ne devrait y avoir qu'un seul modèle par vue, ce qui signifie qu'il devrait y avoir des classes distinctes pour le modèle de domaine qui est appelé dans le modèle de présentation pour le modèle de présentation. la vue donnée? – Klik
@Klik Il est impossible de donner une seule réponse à cette question , parce que cela dépend de votre motivation à vouloir implémenter un design donné. Si vous voulez avoir un modèle de domaine distinct, vous vous aventurez dans le territoire de l'architecture d'applications en couches, et il y a des coûts associés: http://blog.ploeh.dk/2012/02/09/IsLayeringWorththeMapping –
est exactement ce que j'ai besoin de lire, merci! – Klik
Si je veux rejoindre ces 3 tables, où dois-je mettre le code? – Billy
De plus, si vous avez une relation «plusieurs à plusieurs», vous aurez généralement une table pour représenter la relation qui ne serait probablement pas représentée par un modèle. –
la manière la plus évidente est l'ajout d'une propriété à une classe représentant les données associées. (c'est-à-dire que la classe 'Customer' aura une propriété nommée 'Orders' qui sera une collection de type 'Order' classe (BTW vous pouvez envisager d'utiliser le framework ADO.NET Entity qui fait tout ça pour vous) – yosig81