Normalement, j'ai un contrôleur et un modèle. Existe-t-il un modèle de disgn pour avoir 1 Vue avec plusieurs Contrôleurs et plusieurs Modèles. Où le contrôleur peut avoir plusieurs modèles, aussi?MVC en C#: Modèle - relation de contrôleur
Certains liens vers des modèles liés seraient agréables.
En général, un contrôleur ne possède qu'un seul modèle. Toutefois, vous pouvez créer un modèle composite qui a lui-même plusieurs modèles.
class CompositeModel
{
private ModelA modela;
private ModelB modelb;
}
Ensuite, faites en sorte que votre contrôleur soit tapé à cet endroit. Mais si vous ne savez pas ce que vous faites en fin de compte, c'est un plan qui ne finira que dans les larmes. Mais si vous parvenez à éviter le modèle God Model, il peut être très puissant.
Je recommanderais d'étudier MVC plus en général.
Cela n'aurait vraiment de sens que si vous possédez une hiérarchie de modèles (héritage) où la vue affiche les propriétés communes des différents modèles enfants. Sur le plan conceptuel, cela pourrait fonctionner mais, en pratique, je ne pense pas que cela arrive très souvent. Dans mon code, le seul endroit où j'approche quelque chose comme ça est avec un champ Contact. J'ai un modèle d'utilisateur qui a un contact d'individu et un contact d'urgence. Les deux contacts sont du même type avec le différentiateur étant si la relation est "soi" ou autre chose. J'ai une vue unique pour créer ces contacts et cette vue est rendue par 2 actions différentes sur le même contrôleur - CreateContactInformation et CreateEmergencyContact. Même dans ce cas, cependant, les deux utilisent le même modèle - Contact. J'aurais pu choisir de sous-classer le modèle, mais il n'y avait pas vraiment de distinction suffisante pour justifier cette complexité.
Dans le cas général, je dirais qu'une vue est utilisée par un seul contrôleur et que chaque contrôleur traite un seul modèle primaire. Les modèles auxiliaires au primaire peuvent être gérés par le contrôleur principal ou avoir leur propre selon la façon dont vous voulez structurer l'application.
Il existe d'autres méthodes qui ont été développées depuis MVC à savoir Model View Presenters. Here sur le site de Martin Fowler est un bon aperçu de ces modèles.
Ma propre application utilise une vue passive, car elle nous permet d'extraire une interface utilisateur et de remplacer facilement une autre. Ceci est un avantage pour nous car notre logiciel est une application CAO/FAO destinée à être utilisée avec une variété de machine de découpe de métal.
Nos formulaires sont des coques minces qui appellent une couche d'interface utilisateur. Les formulaires implémentent une interface et s'enregistrent avec la couche d'interface utilisateur. Nous avons une variété de formes utilisées à des fins différentes. Par exemple un formulaire de configuration où l'utilisateur modifie les paramètres de configuration étendus pour la machine qu'il utilise, une forme d'entrée de forme, une forme de découpe de métal où l'utilisateur positionne les formes à couper. Toutes ces formes ont une interface utilisateur distincte.
La forme de coupe de métal est également différente entre différents types de machines. On peut montrer une vue WYSIWYG d'une plaque de métal plate. Un autre est une grille de style tableur des pièces à couper dans l'ordre où ils seront coupés. Un autre montre encore les pièces positionnées sur un tuyau tournant.
La couche d'interface utilisateur à son tour prend l'entrée et exécute les commandes. Les commandes à leur tour interagissent avec le calque d'interface utilisateur et le modèle. Presque tout est géré par des objets de commande, par opposition aux appels directs par des méthodes.
Cette structure permet de connecter plusieurs interfaces utilisateur au même modèle. Au sein d'une interface utilisateur spécifique, une variété de vues peut être prise en charge. Ce que j'ai marqué comme modèle pourrait être des bibliothèques séparées. Ils ne seraient combinés qu'au niveau de la couche d'interface utilisateur et au-dessus via les composants de l'interface utilisateur référençant les différentes bibliothèques.
La hiérarchie ressemble à ceci.
Thats la manière que je vais maintenant. Parce que je n'ai qu'une seule vue, je pense que toutes les données pour cette vue doivent provenir du seul et unique modèle. On dirait que je dois diviser ma vue en plusieurs parties pour éviter un modèle de dieu s'il pousse vraiment trop. – Tarion
Une chose que je fais est de limiter la responsabilité de CompositeModel à la gestion (d'événement) des sous-classes. – Tarion