Discussion :

[coolcoco]

C'est pas compliqué, sauf à expliquer !

Merci de toutes ces explications!

Je suis désolé de revenir encore une fois avec une question mais si mon arborescence de mon dossier application est:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
application
  /default
    /controllers
    /models
    /views
  /engine
    /controllers
    /models

selon http://framework.zend.com/manual/en/...r.modular.html

J'aurais donc par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
application
  /default
    /controllers
    /models
      /Default
        /Db
          /Table
    /views
  /engine
    /controllers
    /models
      /Engine
        /Db
          /Table

C'est bien juste?

[Invité]

Merci de toutes ces explications!

Je suis désolé de revenir encore une fois avec une question mais si mon arborescence de mon dossier application est:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
application
  /default
    /controllers
    /models
    /views
  /engine
    /controllers
    /models

selon http://framework.zend.com/manual/en/...r.modular.html

J'aurais donc par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
application
  /default
    /controllers
    /models
      /Default
        /Db
          /Table
    /views
  /engine
    /controllers
    /models
      /Engine
        /Db
          /Table

C'est bien juste?

Oui c'est bien juste , mais ...

Selon ton exemple tu devras nommer tes classes métier de cette façon :

Default_Db_Table
Engine_Db_Table

Les préfixes sont un peu long non ? Tu pourrais utiliser uniquement les 2, 3 ou 4 premières lettres du module métier pour te simplifier les choses...

Par ex. le répertoire "Default" se nommerait "Def", le répertoire "Engine" "Eng"
Et les classes Def_Db_Table, Eng_Db_Table...

Ca devient particulièrement utile si tu as des longs noms de modules.

Bye

P.S (pour tout le monde) : Conventions de codage PHP du Zend Framework.

[sekaijin]

Merci de toutes ces explications!

Je suis désolé de revenir encore une fois avec une question mais si mon arborescence de mon dossier application est:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
application
  /default
    /controllers
    /models
    /views
  /engine
    /controllers
    /models

selon http://framework.zend.com/manual/en/...r.modular.html

J'aurais donc par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
application
  /default
    /controllers
    /models
      /Default
        /Db
          /Table
    /views
  /engine
    /controllers
    /models
      /Engine
        /Db
          /Table

C'est bien juste?

je ne suis pas d'accord
au niveau de ton métier ta classe représente un objet de ton métier
Client, Facture, Automobile, Boulon, Artistes, Album etc.

le contrôleur n'a pas à savoir que ton objet métier dépends d'une base de donnée ou d'un annuaire LDAP ou de tout autre chose
C'est à ton métier de se débrouiller avec sa source de donnée. ainsi si elle change c'est ton objet métier qui change et non pas l'ensemble de ton application.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
application
  /default
    /controllers
    /models
      Client.php
      /Client
        Table.php
    /views
  /engine
    /controllers
    /models
      Automobile.php
      /Automobile
          /Table.php

Le contrôleur dans default accéde à Client.php en fonction de ses besoin ce dernier lui pioche dans model/Client pour utiliser les classes dont il a besoin. par exemple Table.php si la source devient LDAP tu place là une classe Ldap.php qui fait le nécessaire et tu modifie Client.php ainsi ton control leur ne change pas.

Le modèle est le modèle logique de ton application le métier ce n'est pas la représentation que tu à choisis pour l'implémenter.
rien n'interdit à Client.php d'utiliser Facture_Table s'il en a besoin mais ce n''est pas Facture_Table qui doit être utilisé par le contrôleurs pas plus que Client_Table ou Client_Ldap

A+JYT

[Invité]

je ne suis pas d'accord
au niveau de ton métier ta classe représente un objet de ton métier
Client, Facture, Automobile, Boulon, Artistes, Album etc.

le contrôleur n'a pas à savoir que ton objet métier dépends d'une base de donnée ou d'un annuaire LDAP ou de tout autre chose
C'est à ton métier de se débrouiller avec sa source de donnée. ainsi si elle change c'est ton objet métier qui change et non pas l'ensemble de ton application.

[...]

Le modèle est le modèle logique de ton application le métier ce n'est pas la représentation que tu à choisis pour l'implémenter.
rien n'interdit à Client.php d'utiliser Facture_Table s'il en a besoin mais ce n''est pas Facture_Table qui doit être utilisé par le contrôleurs pas plus que Client_Table ou Client_Ldap

A+JYT

Tel quel, tu introduis un problème de conception orientée objet, ça n'a plus grand chose à voir avec les conventions de codage de ZF (c'est la problématique récurrente ici).

On pourrait effectivement introduire une abstraction entre les classes métier et les contrôleurs mais à ce moment là "Engine/Client.php" devrait étendre la classe abstraite, Engine/Abstract.php. De cette manière la convention de codage serait respectée. (Engine_Client extends Engine_Client_Abstract).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
application
    /default
      /controllers
      /models
         /Default
             Client.php
             Abstract.php 
            /Db
               /Table

Note : Si cette couche d'abstraction n'a pas été définie durant la phase de conception (et que les contrôleurs utilisent directement les classes concrètes) : on peut progressivement refactoriser la structure en définissant une interface, le cas échéant, Engine/Interface.php

[coolcoco]

Merci de vos réponses...

Je viens du monde Ruby on Rails... et jusqu'à maintenant je mettais toute la logique de l'application directement dans les contrôleurs. C'est marrant de voir que c'était pas forcement à 100% juste.

PS: Guardian_7, aussi neuchâtelois à ce que je vois ;-)

[Invité]

Merci de vos réponses...

Je viens du monde Ruby on Rails... et jusqu'à maintenant je mettais toute la logique de l'application directement dans les contrôleurs. C'est marrant de voir que c'était pas forcement à 100% juste.

PS: Guardian_7, aussi neuchâtelois à ce que je vois ;-)

Le monde est petit

C'est bien de savoir remettre ses méthodes en question, de temps en temps !

[bbmt]

Bonjour,
et bien lorsque je vois une discussion comme celle là, je me dis que ceux qui pensent qu'avec PHP on programme mal n'ont qu'a bien se tenir.

Bon je rajoute ma pensée qui vaut ce quelle vaut mais bon.

Pour moi le M de MVC veut clairement dire metier. et pour moi l'arborescence suivante n'est pas la meilleur:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
application
  /default
    /controllers
    /models
    /views
  /engine
    /controllers
    /models

en effet par exemple si j'ai un module panier et un module article, le panier aura surement besoin du model article pour verifier si il reste des articles. Donc pour moi tous les modeles doivent etre dans un seul dossier extérieur au module:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
application
  /default
    /controllers
    /views
  /engine
    /controllers
    /views
  /models
    /panier
      PanierMetier.php
      /table
        PanierTable.php

comme ça toute les classe métier sont accessible par n'importe qu'elle module et on encapsule l'accès aux différent type de donnée (fichier , mysql ...)

Et enfin , merci à developpez.net pour fournir des discussions comme celle-ci.

[__2mx]

Donc pour moi tous les modeles doivent etre dans un seul dossier extérieur au module:
...
comme ça toute les classe métier sont accessible par n'importe qu'elle module et on encapsule l'accès aux différent type de donnée (fichier , mysql ...)

Ça se discute, l'avantage des modules c'est de découper ton application en sous unités indépendantes mais aussi de les rendre portables.

Si aujourd'hui je développent un module pour gérer des contacts et que d'autres veulent l'utiliser il faudrait que dans le meilleur des mondes il puissent l'installer par un simple copier/coller. Mais ça se complique si j'ai une partie des modèles hors du module.

Mais rien empêche un module d'accéder au modeles d'un autres. Donc demain je peux très bien développer un module newsletter qui aura besoin du module contacts pour fonctionner. newsletter utilisera alors la logique métier de contacts pour récupérer les contacts inscrit à la newsletter.

Cette logique reste aussi valable pour une webagency qui pour chaque projets va réutiliser un ou plusieurs modules déjà développés. Dans ce cas, il ne faut pas que les intégrateurs aient à courir après des bouts de code à gauche et à droite.

Donc tout dépend des objectifs, mais j'aurai tendance a laisser mes modeles dans les modules.

--
Laurent