Dans MVC, quelles sont les limitations du contrôleur?

Question

Le contrôleur doit-il effectuer des affectations directes sur les objets Modèle, ou simplement indiquer au modèle ce qui doit être fait?

Answer 1

Le contrôleur possède deux fonctions classiques:

1. gérer l'événement d'entrée de l'interface utilisateur (gestionnaire ou rappel déposée)

2. avertir le modèle d'une action - qui peuvent ou peuvent ne pas résulter un changement sur l'état du modèle

il ne fonctionne pas la validation des données, qui est sur le modèle, ni avoir son mot à dire dans la façon dont l'information est présentée.

Answer 2

Les services de modèle n'ont pas besoin de connaître l'existence du contrôleur, ainsi, le contrôleur peut faire ce dont la vue a besoin en utilisant les services de modèle.

Answer 3

Cela dépend largement de la portée de votre application. Si c'est relativement rapide et sale, alors il n'y a aucun sens dans la sur-ingénierie, et bien sûr, vos contrôleurs peuvent parler à vos objets de modèle. D'un autre côté, s'il doit être plus «entreprenant» pour une raison quelconque, un bon modèle à utiliser conjointement avec MVC est ce qu'on appelle le «Business Delegate». C'est ici que vous pouvez composer des méthodes grossières à partir d'une ou de plusieurs méthodes sur un ou plusieurs objets du modèle; par exemple, supprimer un objet et retourner une liste rafraîchie sans cet objet. Cette couche donne deux avantages. D'une part, il déconnecte les contrôleurs de tout système ORM utilisé pour les objets du modèle. De plus, c'est la couche qui doit finalement traiter de façon constructive toutes les exceptions qui peuvent avoir eu lieu au lieu de les relancer.

Answer 4

Je ne pense pas qu'un contrôleur devrait traiter des objets de modèle.

J'ai tendance à penser que le contrôleur fait vraiment partie du niveau de l'interface utilisateur. Je préfère injecter une couche de service entre le contrôleur et le reste de l'application. Le niveau Web accepte les requêtes HTTP, les paramètres unmarshals des objets de la demande dans les objets avec lesquels l'interface de service peut traiter, et la réponse à renvoyer. Tout le travail avec les transactions, les unités de travail, et traitant des objets de modèle et de persistance est fait par le service.

Cette approche est davantage axée sur le service. Il sépare le service de l'interface utilisateur, laissant la possibilité à plusieurs clients de réutiliser le même service. Cela rend la couche qui demande les services au service "mince", il est donc facile de désactiver les services SOAP pour REST ou EJB ou CORBA ou quoi que ce soit de nouveau.