La meilleure option est d'utiliser #2 approche, avec quelques modifications.
Je voudrais écrire quelque chose comme ceci:
public function postLogin( $request )
{
$service = $this->serviceFactory->build('Recognition');
$service->authenticate( $request->getParam('username'),
$request->getParam('password') );
}
// Yes, that's the whole method
Il n'est pas nécessaire de créer des variables, si vous avez utilisé quelque chose comme un Request exemple de résumé l'entrée de l'utilisateur.
Aussi, vous pouvez remplacer l'Request::getParam()méthode avec quelque chose commeRequest::getPost()- bien que j'en suis venu à la conclusion que, dans une application structurée, l'GETetPOSTparamètres ne doivent pas partager le même nom.
L' serviceFactory qui vous voir dans l'extrait de code serait un objet que vous injectez dans le contrôleur et la vue de l'instance. Il vous permet de partager les mêmes instances de service entre les contrôleurs et les vues.
Il est responsable de la création de services (qui contient la logique de l'application, tout en laissant le domaine de la logique métier dans le domaine des objets), qui vous aide à isoler l'interaction entre le domaine des entités et de stockage des abstractions à partir de la couche de présentation.
Sur les autres options:
-
Le Contrôleur appelle le Modèle et le Modèle de gérer les $_POST données.
Dans le MVC et MVC-inspiré des modèles de conception, le modèle devrait être au courant ni de l'interface utilisateur, ni de la couche de présentation dans son ensemble. L' $_POST variable en PHP est une superglobale.
Si vous l'utilisez avec le modèle de couche, votre code est lié à l'interface web et même la demande de la méthode.
-
Les transformations du Contrôleur $_POST les données dans un Modèle objet et seulement passer de l'objet à modéliser
Pas entièrement sûr de ce que vous entendez par cela. Semble que vous parliez de l'instanciation d'une abstraction, qui contiendrait à la demande de l'utilisateur. Mais dans ce cas, le contrôleur est responsable de l'instanciation/création de ladite structure, ce qui constituerait une violation du PRS.
La fermeture de notes:
Une chose que vous devez comprendre, c'est que, dans le contexte de basée sur le web applications MVC, l' Utilisateur de votre application est le navigateur. Pas vous. Navigateur envoie la demande, qui est géré par le mécanisme de routage et diffusé par le contrôleur. Et vue produit la réponse à votre navigateur.
Et l'autre chose, c'est: Modèle n'est ni une classe, ni un objet. Le modèle est une couche.
Mise à jour
Généralement, le même Contrôleur gère la demande à partir d'un navigateur, d'un service web, une application hors connexion, etc, ou chacun dispose de son propre Contrôleur?
Vous devriez être en mesure d'avoir un seul contrôleur, qui traite de toutes les formes de la demande. Mais c'est seulement à la condition, vous êtes réellement en utilisant la même application pour toutes les 3 cas d'utilisation.
Pour ce faire il y a deux conditions:
- vous avez besoin d'abstraire l'
Request exemple, que le contrôleur reçoit
- la vue doit être instancié à l'extérieur du contrôleur
De cette façon, vous pouvez avoir une application pour répondre à toutes les exigences. Seule chose, que chaque variante possède différents, est l'étape bootstrap, où vous créez l' Request instance et sélectionnez la vue appropriée.
Dans la situation que vous avez décrite, l'évolution de la partie serait effectivement la vue, depuis un REPOS ou de service SOAP devrait produire une réponse différente qu'une simple application web.
