Logique de contrôleur et logique de modèle, où dessinez-vous la ligne avec pagination?

Le but d'un framework MVC est de séparer la conception (templates) de la logique (controllers). Cependant, les langages de gabarit offrent souvent un degré limité de «logique de conception». Cela inclut les instructions if de base, les boucles, le filtrage, etc.Logique de contrôleur et logique de modèle, où dessinez-vous la ligne avec pagination?

J'ai créé une balise de modèle Django qui peut prendre n'importe quelle liste ou QuerySet et la "pagifier". Il divise la liste en pages en fonction d'une taille de page spécifiée, puis ajoute les pages dans le contexte. L'utilisation est comme suit:

{% pagify articles by 20 as pages %}

Je peux alors appeler un comprennent séparé pour itérer sur les pages et produire une belle liste de pages où je en avais besoin.

Cela m'a semblé une façon optimale de le faire car cela me permettait de faire une recherche dans n'importe quelle liste dans le contexte; Je n'ai pas eu à compter sur le contrôleur pour renvoyer les résultats paginés. Mais un collègue a fait valoir que cela semblait trop logique pour le modèle. Je pensais que cela relevait encore du domaine de la logique basée sur le design puisque la page fonctionnerait encore sans pagination, et la détermination de la taille de la page semble être une responsabilité de modèle.

Ma question, est-ce trop logique pour le modèle? ou est-ce une façon propre de gérer cela?

Source

2009-03-17 Soviut

Votre collègue a l'air d'un gars plutôt intelligent. : P –

Dit de cette façon; Que se passerait-il si vous utilisiez votre modèle de données sur un autre support, par exemple, pas sur le Web, mais via une application basée sur la console ou une tâche d'arrière-plan? Ne serait-il pas agréable de pouvoir obtenir des «pages» de données par l'intermédiaire d'un contrôleur (ou d'un gestionnaire) plutôt que d'avoir à utiliser un modèle pour faire ce travail pour vous? Bien que je sois certainement d'accord pour que le "look" des données paginées soit géré par votre template, le "act" de la pagination devrait être laissé à un contrôleur (vue Django) ou même à travers une sorte de custom gestionnaire (models.Manager) méthode.

Source

2009-03-18 05:16:56

très bon point, je ne considérais pas une portée aussi large, principalement à cause du chargement paresseux que QuerySets dans Django permet. Une fois que vous commencez à traiter des données JSON et d'autres vues qui ne rendent pas les modèles, ma solution ne fonctionne pas. – Soviut

+1 pour le gestionnaire personnalisé comme moyen de pagination. Ce ne serait pas aussi automatique que ma solution de gabarit, mais c'est une façon élégante de traiter les pages directement du modèle. – Soviut

Même accord pour les thèmes/skins du site. Si vos clients peuvent choisir la peau qu'ils veulent, ils s'attendent probablement à ce que la pagination fonctionne de la même manière. Je suis d'accord que si c'est un one-liner ce n'est pas un gros problème; mais en principe, la pagination ne devrait pas dépendre autant de la présentation. –

La vue ne doit pas contenir de logique métier ou de logique de navigation. Ce que vous décrivez est la fonctionnalité de présentation (évitant soigneusement le l-mot ici), qui peut être placé dans la couche de vue.

Source

2009-03-17 21:44:23

Je suis d'accord avec votre collègue; le modèle doit être alimenté par des données paginées plutôt que d'effectuer la pagination. La question clé, je pense, est de savoir si la détermination de la taille de la page est un devoir de modèle, et je ne le pense pas; Je dirais que cela devrait être traité à un niveau supérieur.

Source

2009-03-17 21:44:31 chaos

Bon point, ma balise de gabarit * doit * vérifier la demande d'une variable? Page = 1. C'est la partie qui le rend plus centré sur la vue. – Soviut

J'ai toujours compris que la vue n'est pas supposée dépourvue de logique. C'est supposé être dépourvu de toute logique de contrôleur. La pagination a juste à voir avec la manière dont les données sont affichées, ce qui correspond exactement à la logique de la vue.

Source

2009-03-17 21:45:30

+1. Déplacer la logique de présentation dans la logique métier juste parce que sa logique est une mauvaise chose. Dans certaines langues, vous devez faire cela parce que la langue du template est si faible, mais si vous avez tout le Python à portée de main, il n'y a pas besoin. – bobince

Mon problème n'était pas tant d'avoir une logique * quelconque * dans les modèles, juste si la pagination était considérée comme une logique de modèle ou une logique métier. – Soviut

Vous souhaiterez peut-être vérifier django-pagination, qui fournit une balise de modèle similaire.

Source

2009-03-18 11:59:49

Logique de contrôleur et logique de modèle, où dessinez-vous la ligne avec pagination?

Répondre

Questions connexes