Pertinence d'un pattern MVC

Bonjour à tous,

Alors j'ai parcouru le forum et suis tombé sur ce sujet : http://www.developpez.net/forums/d36...end-framework/ qui semblait correspondre à ce qui me préoccupe en ce moment.

Je suis en charge d'un projet de développement d'une sorte d'ERP interne spécifique à mon entreprise, projet que je vais développer en PHP.

Comme je manque d'expérience en la matière je me suis (beaucoup) documenté, et de cette documentation et de divers essai me sont venues plusieurs réponses :
1. en l'absence de réelle équipe projet, et compte tenu des capacités limitées de l'infrastructure en production (dont l'évolution ne fait pas partie du projet); l'utilisation d'un framework type Zend, semble engranger plus de difficultés et de contraintes que d'intérêt
2. l'utilisation d'une démarche métier et l'application d'un design pattern est toutefois indispensable pour garantir la maintenabilité de l'application

J'en suis donc venu à m'intéresser à MVC (et ai consulté par exemple le tutoriel : http://tahe.developpez.com/web/php/mvc/ ), ainsi que d'autres.

Toutefois certaines choses ne sont pas encore très claires dans mon esprit, j'espère que vous pourrez m'aider :

- un pattern MVC doit-il nécessairement impliquer du développement orienté objet ? (personnellement c'est principalement PDO et les requêtes préparées qui m'ont fait choisir PHP5)
- une arborescence spécifique (comme cela était décrit dans le tutoriel sur le ZF : application/ application/models application/views application/controllers ) entrainera-t-elle des problèmes au niveau de la manipulation des appels des scripts ? (surtout au point de vue des chemins)

Merci d'avance de vos réponses :)

Bonjour,

Un avis qui n'engage que moi ;)

Citation:

---

Envoyé par madmaxou

- un pattern MVC doit-il nécessairement impliquer du développement orienté objet ? (personnellement c'est principalement PDO et les requêtes préparées qui m'ont fait choisir PHP5)

---

Les modèles de conception ont été "imaginés" pour répondre à des problèmes courants de conception en POO et éviter de réinventer la roue lorsque ces problèmes sont rencontrés. Personnellement, je ne vois donc pas comment on peut appliquer un pattern sans POO.

Après, ce que tu peux faire, c'est reprendre les idées de ces modèles dans une programmation procédurale (mais ça ne sera pas une application directe du modèle). Pour le MVC, il s'agit de séparer la gestion du modèle (données + gestion métier), de la représentation (vue), un contrôleur gérant les données à récupérer et la vue à présenter pour une demande donnée.

Citation:

---

Envoyé par madmaxou

- une arborescence spécifique (comme cela était décrit dans le tutoriel sur le ZF : application/ application/models application/views application/controllers ) entrainera-t-elle des problèmes au niveau de la manipulation des appels des scripts ? (surtout au point de vue des chemins)

---

Je ne comprend pas ce que tu veux dire par là... Qu'est-ce que tu entend par "manipulation des appels des scripts" ?

D'accord, merci de ta réponse :)
Le fait est que j'ai du mal à assimiler le concept objet avec le développement Web, sans doute par manque de pratique (et je dois avouer que je ne trouve pas le tutoriel de Mr Tahé très clair :? pour ma petite caboche bien sur :P).

Pour ce qui est de mon problème de chemin, si un contrôleur invoque un script métier dans la modèles de l'application, pour ensuite invoquer une vue et renvoyer le tout au contrôleur principal; l'imbrication se fait mal dans mon esprit, surtout si chacun des scripts est dans un chemin bien spécifique, s'il faut jongler avec les différents path, ce ne serait pas très pratique :?

Merci quoi qu'il en soit, je vais voir s'il est pertinent d'orienter mon application de manière objet, et ensuite je dois assimiler ce type d'approche (ce qui n'est pas gagné je le crains :P) si ça l'est bien sur ^^

Ce qui est sûr c'est que ton code sera beaucoup plus maintenable si tu utilises la POO pour regrouper par module les objets qui répondent à la même problématique (le gestionnaire de facture, le gestionaire d'authentification etc...)
Le Pattern MVC t'aide à faire de même au niveau de la partie presentation (IHM) de ton application. Le contrôleur appelle effectivement le Model (qui effectue les traitements) et ensuite il appelle la Vue.

Citation:

---

Envoyé par madmaxou

D'accord, merci de ta réponse :)
Le fait est que j'ai du mal à assimiler le concept objet avec le développement Web, sans doute par manque de pratique (et je dois avouer que je ne trouve pas le tutoriel de Mr Tahé très clair :? pour ma petite caboche bien sur :P).

---

J'étais exactement dans le même cas il n'y a pas si longtemps...
J'ai déjà fais de la programmation objet dans d'autres langages, pour des applications 'classiques', et j'ai eu beaucoup de mal à comprendre quel intérêt ça pouvait avoir pour créer un page web en php (notamment du fait de la non persistance des objets entre deux requêtes).
Je n'en ai en fait compris l'intérêt qu'en me mettant au Zend Framework. Et maintenant, j'aurais du mal à m'en passer ;).

Si tu as des connaissance en POO (utilisation dans d'autres langages), alors ça vaut le coup à mon avis de t'y mettre aussi en php. Par contre, si tu n'as pas d'autre expérience en POO, il est certain que l'investissement sera plus important...

Pour ce qui est de la question d'utiliser des frameworks ou pas [sans parler de performances]... Si tu ne connais pas la POO, tu risques de partir sur une mauvaise conception de ton application qui pourrait devenir très complexe à maintenir. Utiliser des frameworks existants et éprouvés limite les dérives possibles.

J'ai déjà fait de la programmation objet. C'est un concept séduisant c'est sur.

Honnêtement, j'ai jeté un oeil au Zend Framework... je me suis un peu arraché les cheveux dessus, les contraintes de conventions sont certes très utiles (et sur un projet d'équipe, j'irai même jusqu'à dire indispensables) mais lorsque l'on est seul, c'est trop d'aspect à prendre en considération pour une application que l'on souhaite développer relativement vite.

Le saut de la programmation procédurale à la POO en PHP5 me parait pas du tout évident, mais je vais m'y essayer ^-^

Merci de vos réponses et conseils :mrgreen:

Je suis un peu dans le même cas que toi madmaxou. Suis le seul dev web au sein d'une équipe de dév C et du coup je suis le seul a travailler sur mes projet.

J'ai à un moment voulu passer à un framework "renommé" et au pattern MVC parce que "c-la-mode-et-que-tout-le-monde-y-fait-ca" mais j'ai finalement vite renoncé de part les contrainte imposées.

Actuellement je travaille avec un framework maison (du coup nettement plus adapté a mes besoins) et une arborescence de fichier stricte et ça me conviens très bien comme ca.
Ca reste très souple d'utilisation sans pour autant être obliger de faire 3 fichiers et 12 classes pour afficher un hello world (oui bon j'exagère un peu :mouarf:).

Après il est certains que se basé sur un gros framework tel que zend apporte un certaisn cadre à ton travail et les personnes qui passerons derrière toi un jour serons certainement bien content :P

Salut,

de mon point de vu, si tu ne veux pas te prendre la tête pour monter une application simple qui ne nécessite pas une grande maintenabilitée ni de possibilitées trop excentrique, utilises un bootstrap tout simple à base d'include.
Et utilises la puissance du modèle objet pour gérer ta base de données, via un orm ou un générateur de classe par exemple.

Tu sera bien plus productif, sans pour autant te prendre la tête à gérer
1 la persistance,
2 les contraintes d'un FWk tels que Zend, Jelix ou symphony.

Le problème c'est qu'en php on te vends l'ORM avec le MVC et le MVC avec l'ORM..

bye