Zend Framework: Utilisation de modèles et de vues, meilleures pratiques [fermé]

Question

Je suis relativement nouveau en programmation orientée objet. Je comprends assez bien les concepts, mais en pratique, j'ai beaucoup de mal à trouver des informations sur la meilleure utilisation des modèles dans mes applications Zend Framework.

Plus précisément, j'ai un modèle (qui ne prolonge rien) qui n'utilise pas de table de base de données. Il utilise des getters et des setters pour accéder à ses membres protégés. Je me trouve aux prises avec la meilleure façon d’afficher ce modèle dans la vue. Je ne veux pas de logique dans mes modèles de vue, mais je me trouve dans la situation suivante:

Dans mon contrôleur:

$object = new Object();
$object->setName('Foo Bar');
$this->view->object = $object;

Dans mon modèle de vue:

<h2><?= $this->object->getName() ?></h2>

Je n'aime pas vraiment appeler des fonctions dans mes modèles de vue, mais je ne connais pas de meilleure façon de le faire. Je ne veux pas que les membres de mon modèle soient publics, mais je veux fondamentalement obtenir les mêmes résultats:

<h2><?= $this->object->name ?></h2>

Je ne veux pas que mon contrôleur fasse tout le travail de tout savoir sur le modèle:

$object = new Object();
$object->setName('Foo Bar');
$this->view->object = $object;
$this->view->object->name = $object->getName();

Quelle est la meilleure pratique d'utilisation des modèles dans Zend Framework? Quelqu'un peut-il recommander un tutoriel qui m'aiderait à comprendre ce dilemme Modèle / Vue dans Zend Framework?

Answer 1

Une possibilité consiste à utiliser les méthodes magiques __set et __get en PHP. Je les utilise comme ça dans ma classe de modèles abstraits:

abstract class Model_Abstract
{
    protected 
 Une possibilité consiste à utiliser les méthodes magiques __set et __get en PHP. Je les utilise comme ça dans ma classe de modèles abstraits: 

// Mapped from Model_User::_data->last_name and Model_User::_data->first_name
$this->name 


 Cela vous permet de spécifier les getters et les setters des propriétés selon vos besoins mais vous évite de définir des fonctions standard pour chaque propriété, mais uniquement celles pour lesquelles vous souhaitez effectuer un traitement. avant de renvoyer la valeur. Par exemple, j’utilise la fonctionnalité à plusieurs endroits pour modifier les dates conformes à la norme ISO (stockées dans MySQL) dans un format plus compact et lisible par les utilisateurs. 

 En ce qui concerne le contenu de votre contrôleur, je vous conseillerais de consulter  cet article  pour des commentaires spécifiques sur la gestion à placer dans votre contrôleur. 

 Certains pensent qu’ils préféreraient avoir un assistant qui charge automatiquement les modèles dans la vue et contourne le contrôleur. Personnellement, je dirais que dans le contexte de Zend Framework et de PHP, il est logique de passer des modèles dans la vue depuis le contrôleur car leur état dépend souvent de ce qui provient de la requête (ce qui doit absolument être géré dans le contrôleur). 

  Mise à jour:  Conformément aux critiques formulées dans les commentaires, je tiens à souligner que votre couche d'accès à la base de données et votre couche de domaine (ou modèle) sont vraiment deux choses différentes, bien qu'avec Active Record. ils sont mélangés ensemble. J'ai posé  cette question  il y a quelque temps et reçu des commentaires utiles. sur ce sujet. Quoi que vous décidiez de faire avec le modèle, vous souhaiterez fournir une API cohérente pour tous les objets de domaine, quelle que soit l'origine des données du modèle. 

 Je suppose que l'un des avantages de la réponse de Saem est qu'il offre la possibilité de mapper directement les valeurs de propriétés / fonctions renvoyées par un ou plusieurs objets de domaine à l'objet de vue. Théoriquement, l'utilisation dans la vue ressemble à ceci: 

<*>data;

    // Private Data Members assigned to protected 
 Une possibilité consiste à utiliser les méthodes magiques __set et __get en PHP. Je les utilise comme ça dans ma classe de modèles abstraits: 

<*>

 Cela vous permet de spécifier les getters et les setters des propriétés selon vos besoins mais vous évite de définir des fonctions standard pour chaque propriété, mais uniquement celles pour lesquelles vous souhaitez effectuer un traitement. avant de renvoyer la valeur. Par exemple, j’utilise la fonctionnalité à plusieurs endroits pour modifier les dates conformes à la norme ISO (stockées dans MySQL) dans un format plus compact et lisible par les utilisateurs. 

 En ce qui concerne le contenu de votre contrôleur, je vous conseillerais de consulter  cet article  pour des commentaires spécifiques sur la gestion à placer dans votre contrôleur. 

 Certains pensent qu’ils préféreraient avoir un assistant qui charge automatiquement les modèles dans la vue et contourne le contrôleur. Personnellement, je dirais que dans le contexte de Zend Framework et de PHP, il est logique de passer des modèles dans la vue depuis le contrôleur car leur état dépend souvent de ce qui provient de la requête (ce qui doit absolument être géré dans le contrôleur). 

  Mise à jour:  Conformément aux critiques formulées dans les commentaires, je tiens à souligner que votre couche d'accès à la base de données et votre couche de domaine (ou modèle) sont vraiment deux choses différentes, bien qu'avec Active Record. ils sont mélangés ensemble. J'ai posé  cette question  il y a quelque temps et reçu des commentaires utiles. sur ce sujet. Quoi que vous décidiez de faire avec le modèle, vous souhaiterez fournir une API cohérente pour tous les objets de domaine, quelle que soit l'origine des données du modèle. 

 Je suppose que l'un des avantages de la réponse de Saem est qu'il offre la possibilité de mapper directement les valeurs de propriétés / fonctions renvoyées par un ou plusieurs objets de domaine à l'objet de vue. Théoriquement, l'utilisation dans la vue ressemble à ceci: 

<*>data
    public function __construct($data = null)
    {
        // Makes it so that I can pass in an associative array as well as 
        // an StdObject.
        if(!is_object($data)) {
            $data = (object) $data;
        }

        $this->_data = $data;

    }

    public function __get($key)
    {
        if (method_exists($this, '_get' . ucfirst($key))) {
            $method = '_get' . ucfirst($key);
            return $this->$method();            
        }
        else {
            return $this->_data->$key;
        }   
    }

    public function __set($key, $val)
    {
        if ( method_exists( $this, '_set' . ucfirst($key) ) ) {
            $method = '_set' . ucfirst($key);
            return $this->$method($val);            
        }
        else {
            $this->_data->$key = $val;
            return $this->_data->$key;
        }
    }
}


class Model_User extends Model_Abstract
{
    //Example overriding method for the property firstName in the 
 Une possibilité consiste à utiliser les méthodes magiques __set et __get en PHP. Je les utilise comme ça dans ma classe de modèles abstraits: 

<*>

 Cela vous permet de spécifier les getters et les setters des propriétés selon vos besoins mais vous évite de définir des fonctions standard pour chaque propriété, mais uniquement celles pour lesquelles vous souhaitez effectuer un traitement. avant de renvoyer la valeur. Par exemple, j’utilise la fonctionnalité à plusieurs endroits pour modifier les dates conformes à la norme ISO (stockées dans MySQL) dans un format plus compact et lisible par les utilisateurs. 

 En ce qui concerne le contenu de votre contrôleur, je vous conseillerais de consulter  cet article  pour des commentaires spécifiques sur la gestion à placer dans votre contrôleur. 

 Certains pensent qu’ils préféreraient avoir un assistant qui charge automatiquement les modèles dans la vue et contourne le contrôleur. Personnellement, je dirais que dans le contexte de Zend Framework et de PHP, il est logique de passer des modèles dans la vue depuis le contrôleur car leur état dépend souvent de ce qui provient de la requête (ce qui doit absolument être géré dans le contrôleur). 

  Mise à jour:  Conformément aux critiques formulées dans les commentaires, je tiens à souligner que votre couche d'accès à la base de données et votre couche de domaine (ou modèle) sont vraiment deux choses différentes, bien qu'avec Active Record. ils sont mélangés ensemble. J'ai posé  cette question  il y a quelque temps et reçu des commentaires utiles. sur ce sujet. Quoi que vous décidiez de faire avec le modèle, vous souhaiterez fournir une API cohérente pour tous les objets de domaine, quelle que soit l'origine des données du modèle. 

 Je suppose que l'un des avantages de la réponse de Saem est qu'il offre la possibilité de mapper directement les valeurs de propriétés / fonctions renvoyées par un ou plusieurs objets de domaine à l'objet de vue. Théoriquement, l'utilisation dans la vue ressemble à ceci: 

<*>data collection.
    protected function _getFirstName()
    {
        // Do some special processing and then output the first name.
    }
}

Cela vous permet de spécifier les getters et les setters des propriétés selon vos besoins mais vous évite de définir des fonctions standard pour chaque propriété, mais uniquement celles pour lesquelles vous souhaitez effectuer un traitement. avant de renvoyer la valeur. Par exemple, j’utilise la fonctionnalité à plusieurs endroits pour modifier les dates conformes à la norme ISO (stockées dans MySQL) dans un format plus compact et lisible par les utilisateurs.

En ce qui concerne le contenu de votre contrôleur, je vous conseillerais de consulter cet article pour des commentaires spécifiques sur la gestion à placer dans votre contrôleur.

Certains pensent qu’ils préféreraient avoir un assistant qui charge automatiquement les modèles dans la vue et contourne le contrôleur. Personnellement, je dirais que dans le contexte de Zend Framework et de PHP, il est logique de passer des modèles dans la vue depuis le contrôleur car leur état dépend souvent de ce qui provient de la requête (ce qui doit absolument être géré dans le contrôleur).

Mise à jour: Conformément aux critiques formulées dans les commentaires, je tiens à souligner que votre couche d'accès à la base de données et votre couche de domaine (ou modèle) sont vraiment deux choses différentes, bien qu'avec Active Record. ils sont mélangés ensemble. J'ai posé cette question il y a quelque temps et reçu des commentaires utiles. sur ce sujet. Quoi que vous décidiez de faire avec le modèle, vous souhaiterez fournir une API cohérente pour tous les objets de domaine, quelle que soit l'origine des données du modèle.

Je suppose que l'un des avantages de la réponse de Saem est qu'il offre la possibilité de mapper directement les valeurs de propriétés / fonctions renvoyées par un ou plusieurs objets de domaine à l'objet de vue. Théoriquement, l'utilisation dans la vue ressemble à ceci:

<*>

Answer 2

Si seuls les autres développeurs travaillent avec les modèles, je vous recommande de ne leur transmettre que les modèles. Voici un lien vers un message de Jeff Atwood sur MVC Comprendre le modèle-vue-contrôleur

Answer 3

Cela ne concerne pas particulièrement le framework zend, mais le problème est plutôt général, à mon sens.

Il semble que vous soyez sur le bon chemin, au lieu de câbler le modèle à la vue, à l'intérieur du contrôleur. Vous préféreriez avoir ce résumé, particulièrement important si vous cartographiez une tonne de modèles, ou si vous mappez le même modèle encore et encore.

Une chose simple serait d'écrire un tas de fonctions de mappage, ce qui serait bien si tout ce que vous évitiez était de mapper la même chose encore et encore.

Si vous souhaitez une solution plus générale, qui évite également d'écrire ce code de plaque de chaudière et de garder les choses plus sèches, je suggère de créer une classe de mappeur.

Vous pouvez créer un ViewModelMapper, qui prendrait un ou plusieurs modèles et les mappera à la vue.

class ViewModelMapper
{
    public function __construct($view)
    {
        //set the properties
    }

    public function addModel($model, $overrideViewProperty = null)
    {
        //add the model to the list of models to map, use the view's property 
        // name to figure out what to map it to? Allow for an override just in case.
    }

    public function getMappedView()
    {
        //take the view, map all the models
    }
}

Vous pouvez ensuite en faire de même sur votre contrôleur et configurer les mappages. Le contrôleur contrôle donc le mappage, mais toute la plaque de la chaudière et la logique de codage sont centralisées pour toutes les mappes de contrôleur, à l'exception de rares exceptions.

Answer 4

Pour en savoir plus sur l'architecture des modèles, lisez cet article . Cela ne parle pas spécifiquement de la vue, mais ça vaut vraiment la peine d'être lu.

J'ai fini par ajouter une fonction getViewClass () à mes modèles. Le contrôleur appelle cette fonction pour obtenir les variables protégées auxquelles il n'aurait pas accès autrement, et la vue n'a pas à s'inquiéter d'appeler des accesseurs.

//controller
$object = new Object();
$object->setName('Foo Bar');
$this->view->object = $object->getViewClass();

//view template
<h2><?= $this->object->name ?></h2>

Je ne sais pas s'il existe un meilleur moyen de faire le travail dans Zend Framework, mais c'est une solution.