Discussion :

[Bobby McGee]

Bonjour,

Je suis prof en BTS SIO et je me prépare à enseigner le PHP objet en 2ème année. Je me pose des questions sur l'architecture PHP standard que je dois présenter à mes étudiants.

Avant d'être prof, j'ai bossé plusieurs années comme ingénieur dans le monde Java/JEE (à l'époque ça s'appelait J2EE...). Je suis donc habitué à une approche de type Model-Driven Design où on construit un modèle du domaine constitué de classes qui encapsulent les données et la logique métier. Ces classes sont indépendantes de toute technologie de persistance.

Voici un exemple de modèle du domaine dans un contexte simple (serveur de quizz).


L'architecture de mon application est basée sur un modèle en couches. L'accès aux données métier persistantes est fait uniquement dans la couche Persistance (qui est donc une implémentation du pattern Data Access Layer). Si les données métier sont stockées dans un SGBDR, cette couche encapsule les requêtes SQL.



Mon problème est que quand je me documente sur l'architecture en PHP, je ne retrouve pas ce genre de solution. Que ce soit sur des exemples simples de POO ou dans le cadre des classes Modèle d'une approche MVC, les classes métier encapsulent systématiquement les méthodes d'accès aux données persistantes (requêtes SQL, XML, etc).

Si je ne me trompe pas, ces solutions sont une implémentation du pattern Active Record. Il y a quelques années, j'avais lu des critiques qui déconseillaient cette solution.

D'où ma question : l'architecture présentée plus haut est-elle transposable en PHP ? (j'imagine que oui, mais la question sous-entend : est-ce une bonne idée ?). Si non, quelle architecture présenter aux étudiants : un MVC classique ?

Merci d'avance pour vos avis.

[Benjamin Delespierre]

Si je ne me trompe pas, ces solutions sont une implémentation du pattern Active Record. Il y a quelques années, j'avais lu des critiques qui déconseillaient cette solution.

Ce serait réducteur de dire que tous les composants PHP disposant d'une couche modèle le font avec de l'active rectord. Actuellement ce qui se fait beaucoup ce sont les ORM comme Doctrine, Propel ou RedBean.

Ton architecture est parfaitement transposable à PHP bien sûr. L'idée en soi n'est pas mauvaise du tout, juste un peu complexe à mettre en place pour des deuxième années voilà tout (déjà qu'on les perd quand on parle objet alors la délégation ).

Personnellement je préfère le behavior driven development

[Bobby McGee]

Ce serait réducteur de dire que tous les composants PHP disposant d'une couche modèle le font avec de l'active rectord. Actuellement ce qui se fait beaucoup ce sont les ORM comme Doctrine, Propel ou RedBean.

Rebonjour Benjamin

Toutes les implémentations de MVC que j'ai trouvées ont des classes Modèle qui contiennent presque uniquement des méthodes d'accès BD de type findById, selectAll, etc. Il y a dans ces classes très peu de logique métier. Peux-tu me renvoyer vers un ou des exemples d'architectures MVC où ces classes Modèle sont codées différemment ?

Je ne me suis pas renseigné sur les outils d'ORM en PHP. En Java ou C#, c'est limite pour des étudiants à bac+2... Je préfèrerais rester sur des choses simples et "manuelles".

Merci une énième fois

[Benjamin Delespierre]

Toutes les implémentations de MVC que j'ai trouvées ont des classes Modèle qui contiennent presque uniquement des méthodes d'accès BD de type findById, selectAll, etc. Il y a dans ces classes très peu de logique métier. Peux-tu me renvoyer vers un ou des exemples d'architectures MVC où ces classes Modèle sont codées différemment ?

C'est un peu normal qu'on ne mette pas les traitements métiers à coté des méthodes d'accès au données non ? Sinon on aboutit à des classes ayant trop de responsabilités.

Au sein d'une archi MVC, les classes de modèle sont supposées représenter la donnée et assurer sa persistance mais elle n'a pas vocation à effectuer d'autres traitements que les opérations CRUD basiques. la séparation entre métier et modèle n'est pas bien claire effectivement, je préfère pour ma part séparer le métier du modèle au niveau des interfaces en suivant la relation "Le métier délègue la persistance au modèle".

[ascito]

la pour le coup sans me tromper, c'est particulièrement une relation Base de donnée -> serveur, ( au moins pour le shema Quizz ) ;

le fait est qu'en php, il existe des choses, comme une couche service et d'autres..

le fait est que la partie vivante de l'objet au niveau user est assez pauvre, sauf a utiliser la mekanique lourde tel qu'une session navigateur

mais finalement, le php est intégré au serveur, donc tu lui demande cela ou ceci et il le fait/// regarde un peu les docs, a l’époque tu pouvais faire de la CB etc...

l'avantage etant principalement, de ne pas a avoir a compiler, de pouvoir ranger les fichiers ( avoir une logique ) , et que ce soit reproductible sur plusieurs environnements....

[ovh]

Active record, en effet c'est mal...

Quelques lectures qui détaillent pourquoi :
http://stackoverflow.com/questions/1...and-propel-1-6
http://programmers.stackexchange.com...ign-principles
http://misko.hevery.com/2009/05/05/t...active-record/

En résumé, le problème d'active record, c'est le couplage très fort entre les classes métier et la couche persistance.

Tu peux aussi effectuer des recherches sur les termes "data mapper", "domain driven design" et "soa" (service oriented architecture). Tu verras que ça correspond plutôt bien à l'architecture que tu nous présentes dans ton premier post

La plupart des ORM ou des couches d'accès aux données de frameworks classiques tels que Zend suivent le pattern active record parce que c'est plus simple...

Mais Doctrine 2 (PHP) et SQL Alchemy (Python) sont 2 ORM à contre-courant basés sur le pattern data mapper : ils sont tous 2 très fortement inspirés par le célèbre ORM Hibernate (java) dont ils reprennent quasi tous les concepts.