Votre organisation (mvc)

23 réponses

Page 1 2

Auteur	Message
tonguide \| Modérateur Inscrit le : 09/05/2005	# Le 25/11/2014 à 16:09 Salut tout le monde. Je cherche à savoir comment vous vous organisez au niveau dev avec l'archi MVC, jusqu'à maintenant, je mettais le controller dans un fichier à accès direct, chose que je voudrais changer en objet (donc via des class Controller). Dans l'optique de faire bien, j'aurai quelques questions à poser à ceux qui utilisent l'archi MVC pour leur projet. A savoir, voici l'organisation que j'ai décidé de faire : -- app (tout ce qui concerne spécifiquement le site en cours) ----- application (class généraliste, tel que le registre, template, abstraction model/controller, autoloader) ----- controller ----- model ----- local (pour multi langue) ----- temp (tout ce qui est cache, log etc.) ----- module (je ne sais pas si c'est une bonne idée, un module comprenant template/controller/model pour insérer un "voir aussi" par exemple, mais pourquoi pas pousser le vis pour afficher les commentaires sur un article etc., rien n'empêchant d'utiliser un model existant évidemment, voir un controller) -- lib (ma lib et les autres) ---- malib ---- smarty / twig ---- etc. -- static (js / css / images) .htaccess index.php < avec le router vers les controller 1 . Comment faites vous de votre côté ? 2 . Et du coup, au niveau des "use" (namespace etc.), vous vous tapez des noms à rallonge du genre new Lib\Malib\Maclass new App\Controller\Blog etc. à chaque fois ? Ou vous avez adapté l'autoloader pour que ce soit moins fastidieux ? Ou justement vous faites un "use App\Model" à chaque fois ? 3 . niveau controller, vous faites une class par page, ou plutôt une method par page (ou ça dépend ...) ? 4 . Après ce n'est peut-etre pas judicieux, mais je fais le traitement des données venant de la BDD directement dans le model, quel est la contrindication ? (je trouve ça plus pratique en faites, ça permet d'avoir le résultat bien propre dès le premier appel). N'hésitez pas à détailler votre méthode, sait-on jamais qu'il y a des méthodes plus pratiques (parce que bon, niveau MVC, c'est à l'appréciation de chacun au final, ce n'est pas si stricte que ça). Merci !
PyRoFlo \| Florent Modérateur Inscrit le : 09/05/2005	# Le 25/11/2014 à 16:37 Il y a autant de réponses possibles que de développeurs. C'est d'ailleurs pour ça qu'on préfère utiliser un framework reconnu, ça évite de tout refaire, tout documenter... et surtout toutes les solutions auront été éprouvées par un tas de personnes différentes ce qui augmente la fiabilité de l'application. Symfony (ou Silex), Zend, Laravel (qui utilise Symfony)... Je pense que le temps que tu vas passer à vouloir bien modéliser ton archi, la tester, développer le workflow de l'entrée d'une requête jusqu'à la réponse envoyée... tu peux l'utiliser à te documenter sur le framework que tu auras retenu. Et le jour où tu feras bosser quelqu'un dessus, il sera opérationnel immédiatement. Bon je sais je réponds pas à tes questions Feu d'artifice Paris
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 25/11/2014 à 16:56 Bah non d'autant que tout ce qui est lib etc. est robuste et utilisé depuis des années déjà, c'est juste une réorganisation, mais en soit je redeveloppe très peu de chose. C'est un peu compliqué à expliquer, mais comme je suis très proche de ce qui est une structure MVC objet, je n'ai que peu d'adaptation à faire, c'est plus l'organisation qui me pose problème et l'utilisation ou non de nom de class à rallonge, que je n'utilisais pas jusqu'à maintenant, après avec l'autoloader, c'est très simple d'en faire sur mesure tout ayant la norme PSR en parallèle. Du coup, je me demande si je reste avec mes noms old school (du genre "Lib_MaClass") ou si je les adapte. J'ai déjà étudié plusieurs docs de FW, sur beaucoup de point je suis très semblable d'ailleurs (surtout Symfony que j'ai quasi entièrement lu), mais j'aime utilisé ma façon. Je me mettrai surement un jour à Symfony qui est le seul qui me plait bien sur le papier (d'autant que le hasard fait que j'ai plein de nom de method identique ). Mais pour le moment, je préfère ma façon (mais en soit, je comprends que tu me dises ça, je m'y attendais)
PyRoFlo \| Florent Modérateur Inscrit le : 09/05/2005	# Le 25/11/2014 à 17:28 1) J'ai 2 front controller (avec ou sans mode débug) qui dispatchent vers le contrôleur adéquat. 2) "use Full\Qualified\Name;' à foison dans chaque fichier sinon c'est illisible et au moins tu sais en un coup d’œil ce qu'utilise ta classe. 3) Moi je fais un controller par domaine fonctionnel. "UserController", "OrderController", "AccountController"... A trop subdiviser on perd en lisibilité, mais c'est très variable selon le projet. 4) Si je devais te conseiller qu'une seule chose ce serait bien cela : ne mêle pas la récupération des données aux objets métiers (les "beans" dans le monde Java). Pourquoi ? Déjà pour alléger tes objets et notamment lors d'une sérialisation. Ensuite parce que tes objets n'ont pas à savoir comment ils sont stockés, si demain tu ajoutes une couche de memcache, redis ou autre, tu ne dois pas avoir à modifier tes objets et donc inutile de rejouer ces tests. C'est plus complexe que de tout mettre dans ta classe métier mais c'est beaucoup plus efficient. Cherche "active record" (en gros, tout dans ta classe métier) et "DAO" (une classe par type de persistance), tu auras d'autres explications. Feu d'artifice Paris
Scull \| Thomas Membre Inscrit le : 06/08/2006	# Le 25/11/2014 à 17:36 1) J'espère que ta structure te permet d'utiliser librement composer et ses nombreux packages, sinon c'est complètement suicidaire de continuer sur du framework maison en 2014... Toutefois ta structure me semble plutôt bonne et conventionnelle. Voilà ce que j'avais utilisé lorsque j'ai du utilisé Silex l'année dernière https://github.com/ScullWM/Silex-kickstarter Maintenant il manque à vu de nez tout ce qui concerne les services/manager, et différencier les forms/handler aussi serait une bonne chose, tu peux vite en avoir bcp dans un projet. J'ai pas vu de dossier concernant tes "vues"... 2) Oui, namespace longs, oui je défini un raccourcis dans l'autoloader pour les class de mes projets 3) pour les controllers je suis plutôt extrément critique, une action ne doit jamais dépasser 10 lignes, sinon c'est quelle traite de la logique métier, et c'est pas son but! 4) ne surtout pas lier tes models à ta librairie mysql/autre, c'est une trés mauvaise idée et pratique... Mon GitHub \| Founder & CEO of [website I made over the weekend]
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 25/11/2014 à 18:08 Merci pour vos 2 réponses. @pyroflo : 1 . pas con l'idée, ça peut permettre de faire facilement de la preprod sans toucher à la prod en bonus. 2 . c'est ce que j'avais compris, c'est mon hésitation 3 . c'est ce que j'avais conclu. 4 . je relis @scull 1 . - elle permet d'utiliser composer oui. - Les forms, je pensais les mettre dans le controller à vrai dire ... Pour le coup, c'est pas idiot de les mettre à part (dans l'absolu, l'admin n'étant pas dans cette config là, j'en aurai peu, mais pour plus tard, autant partir sur de bonne base). Qu'est ce que tu entends par services/managers ? (à priori, on dirait un helper ce que tu as mis dans services, et pour le coup, moi c'est inclus dans "malib"). 3 / 4 . alors là, il va falloir m'aider Je suis d'accord avec l'idée que l'action d'un controller ne devrait pas dépasser les 10 lignes, sinon c'est de toute manière cradingue à maintenir. Mais là, je n'ai pas du comprendre quelque chose. Pour moi le model s'occupe justement des requetes SQL et donc lié à la lib mysql (surcharge PDO en l'occurrence) (prestashop fait ainsi par exemple). Et toi, tu me dis que non, donc ? Et d'ailleurs c'est qu'il me semble avoir également lu sur Symfony (sauf qu'il conseille d'utiliser un ORM). Et c'est surtout sur "sinon c'est quelle traite de la logique métier" qui m'intrigue ... Qui doit traiter les données avant de l'envoyer à la vue, rien que ça peut prendre plus de 10 lignes, ce que j'avais sous traiter au model ? (et quand tu additionnes une dizaine d'info différente sur une page d'accueil par exemple, autant dire que la method du controller peut vite devenir très longue, surtout si on doit faire le traitement des données en prime).
MichaelL \| Michael Membre Inscrit le : 29/01/2009	# Le 25/11/2014 à 18:27 Ma méthode à moi c'est de faire comme Symfony me dit de faire Que ça me plaise ou non, je m'adapte parce que je sais que je ne ferais pas mieux.
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 25/11/2014 à 19:15 Après, symfony n'impose pas d'utiliser MVC à priori, ni même d'être propre dans son code, à en croire le code de phpBB qui utilise Symfony, pour moi c'est un vrai bordel.
Scull \| Thomas Membre Inscrit le : 06/08/2006	# Le 25/11/2014 à 19:24 phpBB utilise des composant symfony (httpfoundation de mémoire), tout comme drupal, thélia, Laravel et bien d'autres. Et c'est pas du tout la même chose que de reposer sur le framework symfony (avec le DIC & co) (Message édité le 25-11-2014 à 20h00 par Scull) Mon GitHub \| Founder & CEO of [website I made over the weekend]
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 25/11/2014 à 19:49 Ah d'accord
Rano \| Jean Modérateur Inscrit le : 13/04/2005	# Le 26/11/2014 à 00:01 @krucial : on peut avoir ton avis ? Chambres d'hote tavel Séjours en provence Forum mariage
nayluge \| Cyril Membre Inscrit le : 09/01/2008	# Le 26/11/2014 à 03:38 Même réponse que MichaelL, je suis les bonnes pratiques de Sf2 car je ferai pas mieux.
Salemioche \| Nicolas Membre Inscrit le : 26/12/2008	# Le 26/11/2014 à 08:06 Je préfère aussi le maison et je fais du new Full\Qualified\Name; et n'utilise pas "use" les lignes sont un peu plus longues, mais jamais d'ambiguité sur la classe
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 26/11/2014 à 12:10 "les lignes sont un peu plus longues, mais jamais d'ambiguité sur la classe" Oui, c'est un peu ma crainte que je me mélange les pinceaux en utilisant des use de partout, quand je vois certains script avec 30 use en début, c'est une galère de fou à s'y retrouver ensuite pour celui qui débarque. Autant je veux bien quand ça dépasse pas les 3, mais parfois, c'est abusé. Je pense que je vais garder mes anciens noms pour ce qui est hors lib externe, plus court, plus pratique et moins de mélange. Une chose que j'avais mal compris (aussi par habitude perso), c'est qu'au final, les traitements des données qui vont à la vue ne doivent pas être faites par le controller, mais justement par la vue. Et au final, c'est tout con mais ça simplifie tout de suite le code, et c'est plus souple au niveau de la vue, donc tout benef. Et ça me permet de garder le model très light, tout en ayant un controller très light également. Je continue mon exploration
PyRoFlo \| Florent Modérateur Inscrit le : 09/05/2005	# Le 26/11/2014 à 12:23 Sur la question des use, si il y en a un tel nombre au point que cela te perturbe, c'est peut être aussi le signe que ta classe n'est pas assez spécialisée. Sinon l'argument "c'est pas lisible je ne m'y retrouve pas avec autant de use" pour moi ça tient pas une seconde : n'importe quel IDE est capable de te dire de quelle classe il s'agit lorsque tu survoles le nom court de la classe. Feu d'artifice Paris
Scull \| Thomas Membre Inscrit le : 06/08/2006	# Le 26/11/2014 à 12:36 tonguide a dit : les traitements des données qui vont à la vue ne doivent pas être faites par le controller, mais justement par la vue OMFG, quand tu parles de traitement fait dans la vue, (j'espère) que tu parles seulement de la mise en forme ? Mon GitHub \| Founder & CEO of [website I made over the weekend]
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 26/11/2014 à 12:47 Exemple : - texte en bbcode > html - texte à securiser > htmlspecialchars - date sql > date en français etc.
Scull \| Thomas Membre Inscrit le : 06/08/2006	# Le 26/11/2014 à 14:33 ouf Mon GitHub \| Founder & CEO of [website I made over the weekend]
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 26/11/2014 à 15:16 Il me reste plus qu'un soucis, cette histoire de Model ... Il y a manifestement 2 façon de faire. CakePhp semble se rapprocher de ta façon de faire (scull), à savoir, plus ou moins généré la requête côté controller, du genre : find('all', array('condition' => array('idCategorie' => $idCat, 'enable' => 1, 'dateExpiry' => '...'), 'orderBy' => 'date DESC')); alors que d'autres s'occupent de la requête côté Model et appel des method (du model) du genre findByCategorie(10) findById(5) etc. La première méthode, je dois avoué ne pas comprendre le gain de temps, si il faut se retaper tous les params à chaque demande légèrement différente d'une autre, c'est pas franchement intéressant, la second est par contre trop rigide, si il faut créer une method à chaque demande particulière, ça n'a pas d'intérêt particulier. Du coup je suis un peu coincé, je réfléchis à un mix des 2 du coup, un peu de param pour être souple, et des fonctions pré-faites pour ne pas refaire le même code. Toujours preneur d'idée (j'en vois qui ne parle pas ! )
PyRoFlo \| Florent Modérateur Inscrit le : 09/05/2005	# Le 26/11/2014 à 15:26 tonguide a dit : La première méthode, je dois avoué ne pas comprendre le gain de temps, si il faut se retaper tous les params à chaque demande légèrement différente d'une autre, c'est pas franchement intéressant, la second est par contre trop rigide, si il faut créer une method à chaque demande particulière, ça n'a pas d'intérêt particulier La première solution est à bannir selon moi, il faut au minimum utiliser des helpers et ne pas attaquer en direct la méthode générique ou alors se contenter d'un ou deux paramètres maximum qui n'ont pas beaucoup de valeurs possibles. La seconde solution est la plus robuste : elle te permet de réutiliser ton code, ça rend plus lisible l'ensemble et tu peux tuner chaque requête. Pour ton mix, tu peux faire un truc comme ça : protected find(array $predicates) { ... } public findByCategorie($cat) { return $this->find(array('categorie_id' => $cat)); } public findById($id) { return $this->find(array('id' => $id)); } ... Feu d'artifice Paris

Auteur

Message

Inscrit le : 09/05/2005

# Le 25/11/2014 à 16:09

Salut tout le monde.

Je cherche à savoir comment vous vous organisez au niveau dev avec l'archi MVC, jusqu'à maintenant, je mettais le controller dans un fichier à accès direct, chose que je voudrais changer en objet (donc via des class Controller).

Dans l'optique de faire bien, j'aurai quelques questions à poser à ceux qui utilisent l'archi MVC pour leur projet.

A savoir, voici l'organisation que j'ai décidé de faire :

-- app (tout ce qui concerne spécifiquement le site en cours)
----- application (class généraliste, tel que le registre, template, abstraction model/controller, autoloader)
----- controller
----- model
----- local (pour multi langue)
----- temp (tout ce qui est cache, log etc.)
----- module (je ne sais pas si c'est une bonne idée, un module comprenant template/controller/model pour insérer un "voir aussi" par exemple, mais pourquoi pas pousser le vis pour afficher les commentaires sur un article etc., rien n'empêchant d'utiliser un model existant évidemment, voir un controller)

-- lib (ma lib et les autres)
---- malib
---- smarty / twig
---- etc.

-- static (js / css / images)
.htaccess
index.php < avec le router vers les controller

1 . Comment faites vous de votre côté ?

2 . Et du coup, au niveau des "use" (namespace etc.), vous vous tapez des noms à rallonge du genre

new Lib\Malib\Maclass
new App\Controller\Blog
etc.

à chaque fois ?

Ou vous avez adapté l'autoloader pour que ce soit moins fastidieux ?
Ou justement vous faites un "use App\Model" à chaque fois ?

3 . niveau controller, vous faites une class par page, ou plutôt une method par page (ou ça dépend ...) ?

4 . Après ce n'est peut-etre pas judicieux, mais je fais le traitement des données venant de la BDD directement dans le model, quel est la contrindication ? (je trouve ça plus pratique en faites, ça permet d'avoir le résultat bien propre dès le premier appel).

N'hésitez pas à détailler votre méthode, sait-on jamais qu'il y a des méthodes plus pratiques (parce que bon, niveau MVC, c'est à l'appréciation de chacun au final, ce n'est pas si stricte que ça).

Merci !

PyRoFlo | Florent
Modérateur

Inscrit le : 09/05/2005

# Le 25/11/2014 à 16:37

Il y a autant de réponses possibles que de développeurs. C'est d'ailleurs pour ça qu'on préfère utiliser un framework reconnu, ça évite de tout refaire, tout documenter... et surtout toutes les solutions auront été éprouvées par un tas de personnes différentes ce qui augmente la fiabilité de l'application.

Symfony (ou Silex), Zend, Laravel (qui utilise Symfony)...

Je pense que le temps que tu vas passer à vouloir bien modéliser ton archi, la tester, développer le workflow de l'entrée d'une requête jusqu'à la réponse envoyée... tu peux l'utiliser à te documenter sur le framework que tu auras retenu. Et le jour où tu feras bosser quelqu'un dessus, il sera opérationnel immédiatement.

Bon je sais je réponds pas à tes questions

Feu d'artifice Paris

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 25/11/2014 à 16:56

Bah non d'autant que tout ce qui est lib etc. est robuste et utilisé depuis des années déjà, c'est juste une réorganisation, mais en soit je redeveloppe très peu de chose. C'est un peu compliqué à expliquer, mais comme je suis très proche de ce qui est une structure MVC objet, je n'ai que peu d'adaptation à faire, c'est plus l'organisation qui me pose problème et l'utilisation ou non de nom de class à rallonge, que je n'utilisais pas jusqu'à maintenant, après avec l'autoloader, c'est très simple d'en faire sur mesure tout ayant la norme PSR en parallèle. Du coup, je me demande si je reste avec mes noms old school (du genre "Lib_MaClass") ou si je les adapte.

J'ai déjà étudié plusieurs docs de FW, sur beaucoup de point je suis très semblable d'ailleurs (surtout Symfony que j'ai quasi entièrement lu), mais j'aime utilisé ma façon. Je me mettrai surement un jour à Symfony qui est le seul qui me plait bien sur le papier (d'autant que le hasard fait que j'ai plein de nom de method identique ). Mais pour le moment, je préfère ma façon

(mais en soit, je comprends que tu me dises ça, je m'y attendais)

PyRoFlo | Florent
Modérateur

Inscrit le : 09/05/2005

# Le 25/11/2014 à 17:28

1) J'ai 2 front controller (avec ou sans mode débug) qui dispatchent vers le contrôleur adéquat.

2) "use Full\Qualified\Name;' à foison dans chaque fichier sinon c'est illisible et au moins tu sais en un coup d’œil ce qu'utilise ta classe.

3) Moi je fais un controller par domaine fonctionnel. "UserController", "OrderController", "AccountController"... A trop subdiviser on perd en lisibilité, mais c'est très variable selon le projet.

4) Si je devais te conseiller qu'une seule chose ce serait bien cela : ne mêle pas la récupération des données aux objets métiers (les "beans" dans le monde Java).
Pourquoi ? Déjà pour alléger tes objets et notamment lors d'une sérialisation. Ensuite parce que tes objets n'ont pas à savoir comment ils sont stockés, si demain tu ajoutes une couche de memcache, redis ou autre, tu ne dois pas avoir à modifier tes objets et donc inutile de rejouer ces tests. C'est plus complexe que de tout mettre dans ta classe métier mais c'est beaucoup plus efficient. Cherche "active record" (en gros, tout dans ta classe métier) et "DAO" (une classe par type de persistance), tu auras d'autres explications.

Feu d'artifice Paris

Scull | Thomas
Membre

Inscrit le : 06/08/2006

# Le 25/11/2014 à 17:36

1) J'espère que ta structure te permet d'utiliser librement composer et ses nombreux packages, sinon c'est complètement suicidaire de continuer sur du framework maison en 2014...
Toutefois ta structure me semble plutôt bonne et conventionnelle. Voilà ce que j'avais utilisé lorsque j'ai du utilisé Silex l'année dernière https://github.com/ScullWM/Silex-kickstarter
Maintenant il manque à vu de nez tout ce qui concerne les services/manager, et différencier les forms/handler aussi serait une bonne chose, tu peux vite en avoir bcp dans un projet.

J'ai pas vu de dossier concernant tes "vues"...

2) Oui, namespace longs, oui je défini un raccourcis dans l'autoloader pour les class de mes projets
3) pour les controllers je suis plutôt extrément critique, une action ne doit jamais dépasser 10 lignes, sinon c'est quelle traite de la logique métier, et c'est pas son but!
4) ne surtout pas lier tes models à ta librairie mysql/autre, c'est une trés mauvaise idée et pratique...

Mon GitHub | Founder & CEO of [website I made over the weekend]

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 25/11/2014 à 18:08

Merci pour vos 2 réponses.

@pyroflo :

1 . pas con l'idée, ça peut permettre de faire facilement de la preprod sans toucher à la prod en bonus.
2 . c'est ce que j'avais compris, c'est mon hésitation
3 . c'est ce que j'avais conclu.
4 . je relis

@scull
1 .
- elle permet d'utiliser composer oui.
- Les forms, je pensais les mettre dans le controller à vrai dire ... Pour le coup, c'est pas idiot de les mettre à part (dans l'absolu, l'admin n'étant pas dans cette config là, j'en aurai peu, mais pour plus tard, autant partir sur de bonne base). Qu'est ce que tu entends par services/managers ? (à priori, on dirait un helper ce que tu as mis dans services, et pour le coup, moi c'est inclus dans "malib").

3 / 4 . alors là, il va falloir m'aider

Je suis d'accord avec l'idée que l'action d'un controller ne devrait pas dépasser les 10 lignes, sinon c'est de toute manière cradingue à maintenir.

Mais là, je n'ai pas du comprendre quelque chose.

Pour moi le model s'occupe justement des requetes SQL et donc lié à la lib mysql (surcharge PDO en l'occurrence) (prestashop fait ainsi par exemple). Et toi, tu me dis que non, donc ? Et d'ailleurs c'est qu'il me semble avoir également lu sur Symfony (sauf qu'il conseille d'utiliser un ORM).

Et c'est surtout sur "sinon c'est quelle traite de la logique métier" qui m'intrigue ... Qui doit traiter les données avant de l'envoyer à la vue, rien que ça peut prendre plus de 10 lignes, ce que j'avais sous traiter au model ? (et quand tu additionnes une dizaine d'info différente sur une page d'accueil par exemple, autant dire que la method du controller peut vite devenir très longue, surtout si on doit faire le traitement des données en prime).

MichaelL | Michael
Membre

Inscrit le : 29/01/2009

# Le 25/11/2014 à 18:27

Ma méthode à moi c'est de faire comme Symfony me dit de faire Que ça me plaise ou non, je m'adapte parce que je sais que je ne ferais pas mieux.

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 25/11/2014 à 19:15

Après, symfony n'impose pas d'utiliser MVC à priori, ni même d'être propre dans son code, à en croire le code de phpBB qui utilise Symfony, pour moi c'est un vrai bordel.

Scull | Thomas
Membre

Inscrit le : 06/08/2006

# Le 25/11/2014 à 19:24

phpBB utilise des composant symfony (httpfoundation de mémoire), tout comme drupal, thélia, Laravel et bien d'autres.
Et c'est pas du tout la même chose que de reposer sur le framework symfony (avec le DIC & co)

(Message édité le 25-11-2014 à 20h00 par Scull)

Mon GitHub | Founder & CEO of [website I made over the weekend]

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 25/11/2014 à 19:49

Ah d'accord

Rano | Jean
Modérateur

Inscrit le : 13/04/2005

# Le 26/11/2014 à 00:01

@krucial : on peut avoir ton avis ?

Chambres d'hote tavel
Séjours en provence
Forum mariage

nayluge | Cyril
Membre

Inscrit le : 09/01/2008

# Le 26/11/2014 à 03:38

Même réponse que MichaelL, je suis les bonnes pratiques de Sf2 car je ferai pas mieux.

Salemioche | Nicolas
Membre

Inscrit le : 26/12/2008

# Le 26/11/2014 à 08:06

Je préfère aussi le maison et je fais du
new Full\Qualified\Name;

et n'utilise pas "use"
les lignes sont un peu plus longues, mais jamais d'ambiguité sur la classe

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 26/11/2014 à 12:10

"les lignes sont un peu plus longues, mais jamais d'ambiguité sur la classe"

Oui, c'est un peu ma crainte que je me mélange les pinceaux en utilisant des use de partout, quand je vois certains script avec 30 use en début, c'est une galère de fou à s'y retrouver ensuite pour celui qui débarque. Autant je veux bien quand ça dépasse pas les 3, mais parfois, c'est abusé.

Je pense que je vais garder mes anciens noms pour ce qui est hors lib externe, plus court, plus pratique et moins de mélange.

Une chose que j'avais mal compris (aussi par habitude perso), c'est qu'au final, les traitements des données qui vont à la vue ne doivent pas être faites par le controller, mais justement par la vue. Et au final, c'est tout con mais ça simplifie tout de suite le code, et c'est plus souple au niveau de la vue, donc tout benef. Et ça me permet de garder le model très light, tout en ayant un controller très light également.

Je continue mon exploration

PyRoFlo | Florent
Modérateur

Inscrit le : 09/05/2005

# Le 26/11/2014 à 12:23

Sur la question des use, si il y en a un tel nombre au point que cela te perturbe, c'est peut être aussi le signe que ta classe n'est pas assez spécialisée.

Sinon l'argument "c'est pas lisible je ne m'y retrouve pas avec autant de use" pour moi ça tient pas une seconde : n'importe quel IDE est capable de te dire de quelle classe il s'agit lorsque tu survoles le nom court de la classe.

Feu d'artifice Paris

Scull | Thomas
Membre

Inscrit le : 06/08/2006

# Le 26/11/2014 à 12:36

tonguide a dit :
les traitements des données qui vont à la vue ne doivent pas être faites par le controller, mais justement par la vue

OMFG, quand tu parles de traitement fait dans la vue, (j'espère) que tu parles seulement de la mise en forme ?

Mon GitHub | Founder & CEO of [website I made over the weekend]

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 26/11/2014 à 12:47

Exemple :
- texte en bbcode > html
- texte à securiser > htmlspecialchars
- date sql > date en français
etc.

Scull | Thomas
Membre

Inscrit le : 06/08/2006

# Le 26/11/2014 à 14:33

ouf

Mon GitHub | Founder & CEO of [website I made over the weekend]

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 26/11/2014 à 15:16

Il me reste plus qu'un soucis, cette histoire de Model ...
Il y a manifestement 2 façon de faire.

CakePhp semble se rapprocher de ta façon de faire (scull), à savoir, plus ou moins généré la requête côté controller, du genre :

find('all', array('condition' => array('idCategorie' => $idCat, 'enable' => 1, 'dateExpiry' => '...'), 'orderBy' => 'date DESC'));

alors que d'autres s'occupent de la requête côté Model et appel des method (du model) du genre

findByCategorie(10)
findById(5)
etc.

La première méthode, je dois avoué ne pas comprendre le gain de temps, si il faut se retaper tous les params à chaque demande légèrement différente d'une autre, c'est pas franchement intéressant, la second est par contre trop rigide, si il faut créer une method à chaque demande particulière, ça n'a pas d'intérêt particulier.

Du coup je suis un peu coincé, je réfléchis à un mix des 2 du coup, un peu de param pour être souple, et des fonctions pré-faites pour ne pas refaire le même code.

Toujours preneur d'idée (j'en vois qui ne parle pas ! )

PyRoFlo | Florent
Modérateur

Inscrit le : 09/05/2005

# Le 26/11/2014 à 15:26

tonguide a dit :
La première méthode, je dois avoué ne pas comprendre le gain de temps, si il faut se retaper tous les params à chaque demande légèrement différente d'une autre, c'est pas franchement intéressant, la second est par contre trop rigide, si il faut créer une method à chaque demande particulière, ça n'a pas d'intérêt particulier

La première solution est à bannir selon moi, il faut au minimum utiliser des helpers et ne pas attaquer en direct la méthode générique ou alors se contenter d'un ou deux paramètres maximum qui n'ont pas beaucoup de valeurs possibles.

La seconde solution est la plus robuste : elle te permet de réutiliser ton code, ça rend plus lisible l'ensemble et tu peux tuner chaque requête.

Pour ton mix, tu peux faire un truc comme ça :

protected find(array $predicates) { ... }
public findByCategorie($cat) { return $this->find(array('categorie_id' => $cat)); }
public findById($id) { return $this->find(array('id' => $id)); }
...

Feu d'artifice Paris

Page 1 2

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.