WebWorker|Club

Votre organisation (mvc)

23 réponses

Page 12

Auteur	Message
Salemioche \| Nicolas Membre Inscrit le : 26/12/2008	# Le 26/11/2014 à 15:28 le find('all''... c'est bien crade quand meme, tu n'as pas vraiment d'abstraction de ton model et le orderBy 'date DESC' colle bien salement à ton model de stockage ( sinon il faudrait parser "date desc" dans le cas ou ce n'est pas une bete insertion dans une req sql ) Tant qu'à mélanger Model/Stockage/Control, autant faire du fichier à plat avec quelques libs
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 26/11/2014 à 15:47 Je n'ai peut-etre pas compris, mais ça me parait bien ça : http://book.cakephp.org/2.0/fr/models/retrieving-y... il précise bien "method du controller". Enfin de toute façon, ça ne me va pas. PyRoFlo, c'est ce que j'avais fais au finish mais avec des methods, malgré tout, ça manque un poil de souplesse. je construit ma requete de cette manière : $this->whereId($id)->whereEnable()->whereNoExpire() etc... Ce qui me permet de contrôler précisément ce que contient par exemple la méthode de non expiration sans me soucier à chaque fois de fournir des critères de date. Ou encore la method whereEnable pourrait prendre la date à laquelle l'article peut être vue, pour programmer à l'avance, et qu'il soit explicitement coché comme valide, mais sans que je m'en préoccupe. Et je comptais passer une partie en paramètre pour ce que je n'ai besoin que de temps en temps. Exemple : en temps normal : $model->limit($page,$parPage)->find(); > me retourne tous les résultats (selon pagination) classement par nombre de clic : $model->limit($page,$parPage)->find(['order' => 'clic']); (qui appelerai par exemple la method orderClic) ça vous parait être une bonne méthode ?
Scull \| Thomas Membre Inscrit le : 06/08/2006	# Le 26/11/2014 à 16:21 Les requètes dans le controller, c'est à éviter à tout prix! Personnellement je sépare au maximum mon model de mes requètes. La construction des requètes est dans un "repository". Aprés, je rajoute encore une couche entre les deux pour plus de souplesse avec l'ajout de "manager". Par exemple mon controller demande au ClientManager la méthode findAll() (qui la demande au repository). Cela permet de facilement modifier les appels à des bases. Car si dans le futur, je souhaite rajouter en paramètre au findAll du repository un temps de cache je peux. Ou si je souhaite merger mes entités "Clients" avec mes entités "prospect", je peux (du moment qu'ils partage une interface en commun). Les managers sont trés adictifs, je les utilisent également pour instancier mes models. (de manière générale, ça centralise tout ce qui concerne tes models) Mon GitHub \| Founder & CEO of [website I made over the weekend]
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 26/11/2014 à 17:08 Je précise que je parlais de construction de requete à partir du model là Bon, j'ai trouvé la solution qu'il me faut ! l'idée étant de faire comme ça (controller ici) : $model->limit($page,30)->find(); // paramètre par défaut $model->limit($page,30)->find($model->orderClic()); // j'écrase le "order by" par défaut par "clic DESC" (mais ça pourrait être "clic DESC, vue DESC"), et en prime je garde l'autocompletion. là je pense que ça reste robuste, tout en gardant une certaine souplesse et en plus je n'ai rien à retenir. J'ai regardé un peu ta méthode Scull, pour le coup, ça va trop loin par rapport à ce que je cherche. Je vais tester cette méthode là, on verra si je rencontre quelque chose que je n'avais pas prévu.

Page 12

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.

© MHN - Tous droits réservés | CNIL N°844440 | 19/04/2024 9:39:25 | Généré en 4.09ms | Contacts | Mentions légales |