Quelle est la bonne façon de les gérer $_POST données dans MVC?

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 instance abstraites de l'entrée de l'utilisateur.

_{en outre, vous pouvez remplacer leRequest::getParam()méthode avec quelque chose commeRequest::getPost()- bien que j'en suis venu à la conclusion que, dans une application structurée, laGETetPOSTparamètres ne doivent pas partager le même nom.}

La serviceFactory que vous voyez 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 des objets du domaine), 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. Le $_POST variable en PHP est un 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 PRS.

De clôture notes:

Une chose que vous devez comprendre, c'est que, dans le contexte de basée sur le web applications MVC, le 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.

De le faire il y a deux conditions:

• vous avez besoin d'abstraire les 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 le 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.

je suis à l'aide de Zend et suivants

la 2ème option .

Exemple d'un formulaire d'Inscription

étape 1 les formes m'envoie la valeur post sur le contrôleur spécifié

étape -2 je vais valider les valeurs d'un formulaire par exemple ( mail et url et vide de valeurs post ) par le biais de la validation côté serveur .

étape -3 envoyer l'objet d'une post données dans la variable ou a tout le modèle .

étape 4- contrôleur appelle le modèle .

étape -5 les modèles insère les valeurs post et crée un nouvel utilisateur .

Je pense que votre deuxième option est la meilleure, indépendamment de cadre ou approah vous utilisez .

note - même contrôleur peut gérer tout dépend de la logique de l'application .

 but i prefer to keep different controller for differnt user request and user types

 it helps in keeping code readable managebale .

'C' est la meilleure option. Vous ne devriez pas laisser brut $de données de POSTES aller dans le modèle comme le modèle est censé être générique de la manipulation de stocker et de charger des opérations principalement.

Exemple : même modèle peut être utilisé de l'interface web et de services Web. Sur le Web $_POST n'est valable que pour les services web de ses pas. Si le modèle ne marche pas soin de la manière dont les données sont reçues, mais seulement la façon de stocker et de le charger.

Yii est certainement un nettoyage de mise en œuvre de la MVC.