Zend FR

Bonjour à tous ;

J'ai passé cette dernière semaine à me "ruiner le cerveau" en lisant tout à tas de documents pour tenter de trouver la meilleurs architecture pour mon application, et plus particulièrement pour ce qui concerne la couche métier.

Les développeurs d'expériences savent que le ZF conduit à une vision assez réduite du M de MVC, notamment par le fait que les composants qu'il fournit ne permettent pas réellement aux développeurs de produire un Domain Model - PofEAA p116 digne de ce nom. J'ai donc parcouru le Web à la recherche du lingot d'or, lu le livre de Martin Flower -  PofEAA, lu le live du Gang of Four (GoF - version français que j'ai acheté et qui est vraiment misérable tant la traduction est mauvaise....) et voici ce que j'en ai conclu:

Les composants fournis par le ZF (je pense notamment à Zend_Db_Table & cie...) ne permettent pas d'implémenter le design pattern Domain Model notamment par le fait qu'étendre Zend_Db_Table ne permet pas de séparer la logique métier de la couche persistance. Aussi, la couche persistance (sans traitement intermédiaire) est directement exposée dans la couche représentation (Le V de MVC). Il y'a aussi tous un tas d'autres raisons qui rendent ces composants incompatibles avec ce design pattern. D'ailleurs, c'est bien normal puisque Zend_Db_Table implémente un design pattern bien spécifique Table Data Gateway - PofEAA p144...

J'ai donc continué mes recherches et suis "tomber" sur un article très intéressant ( http://www.angryobjects.com/2009/03/30/ … -framework ) qui affectionne particulièrement la couche service. Malheureusement, là encore, il apparaît qu'une utilisation intensive de la couche service peur aboutir à un modèle dit "anémique" ( http://martinfowler.com/bliki/AnemicDomainModel.html ), ce qui appauvri grandement l'idée même du modèle de domaine dans la mesure où il fournira plus aucun comportement..

Ainsi, si il semble que la couche service puisse est utilisée de concert avec le modèle, ce n'est pas pour autant que le modèle dans être amputé de tout comportement.

------------------

Première question

Qu'est qui peut faire partie de la couche service et qu'est qui peut faire parti du modèle exactement.. (je parle en terme de comportement)

Deuxième et dernière question:

J'utilise un Data Mapper - PofEAA p165 pour l'accès au données. Ce Data Mapper est donc responsable de la persistance des données.

Si je veux supprimer une entité, je vais nécessairement invoquer une méthode delete() sur mon Data Mapper. La question est: Est-ce que l'objet de domaine (l'entité) doit fournir le comportement lié à sa suppression:

[lang=php]
$postDataMapper = new postDataMapper();
$post = postDataMapper->find(1);

$post->delete();

Ce qui implique que le modèle lui même ait connaissance du Data Mapper et donc, ne respecte pas le fait que normalement, un objet de domaine ne doit pas avoir connaissant du Data Mapper. D'ailleurs autoriser ceci me fait plus penser à une implémentation du design pattern Active Record - PofEAA p160 qu'autre chose...


Merci pour vos éclaircissements.

Note: Je n'ai peux être pas encore tous appréhender de tous ces design pattern architecturaux. Ainsi donc, je vous remercie d'être indulgent à mon égard si je dis quelques bêtises.

Dernière modification par nuxwin (01-05-2011 13:02:46)