Zend FR

Salut,

Je vais encore passer pour le gros lourd de l'architecture mais tant pis

C'est une question à laquelle il est difficile de répondre exactement. Il y a beaucoup de paramètres qui entrent en jeu.

Venant du monde objet, depuis que je suis sur PHP je planche sans arrêt sur la question. Il y a beaucoup de concepts qui chacun prône son excellence, et dans PHP il y a tout à faire (et c'est aussi pour ça que c'est passionnant).

Certains te diront que d'un point de vue vitesse de dev et maintenance c'est mieux d'avoir un modèle métier anemic (en gros des sacs à setters et getters) et de foutre toute la logique métier dans des services (métier, parce qu'en plus il y a des services dans différentes couches, en gros je parle du pattern Service Layer qui facilite la distribution d'une API).

D'autres te diront : "le DDD (Domain Driven Design) c'est le top du top, rendons le métier aux objets métier !" (entre autres parce que le DDD ce n'est pas que ça).

Au départ, je voulais être un "puriste" et je me suis orienté vers un modèle métier riche. Malheureusement, avec les ORM PHP actuels c'est pas tout à fait possible (si tu respectes les conseils du DDD par ex.).
Si on prend Doctrine 1.2, il faudra forcément à un moment transgresser des règles de modélisation métier pour arriver à tes fins, à moins de mapper encore par dessus Doctrine. Avec la version 2, ce problème ne devrait plus exister.
Le problème est que tes objets métiers sont générés par ton ORM et sont le reflet exacte de ta base de données, or, c'est une aberration car on ne devrait jamais construire son modèle métier en fonction de la persistance. Et en réalité, les données que tu vas afficher à un utilisateur sont souvent le mélange de plusieurs états de plusieurs objets métiers. Si tu utilises directement tes objets métiers dans ta vue, tu devras parfois (si la relation n'existe pas dans ta BDD) effectuer autant de requêtes que d'objets différents pour lesquels t'as besoin d'afficher un état.

Bien sûr tout dépend de la dimension de l'appli. Pour une petite application, a faible scalabilité, l'utilisation de Doctrine est un vrai bonheur, pas besoin de plus de couches, du MVC, eventuellement une façade, mais tu consommes directement toutes les fonctionnalités de Doctrine. Et là, le dév est très très rapide.

Maintenant si tu comptes développer une appli distribuée, à forte scalabilité, c'est une toute autre histoire. Mais c'est possible, sans partir trop dans des délires qui pourrissent les performances

L'exemple de Facebook tombe bien. En ce moment je suis sur un projet de site communautaire qui devra proposer éventuellement (en fonction de son succès) une API distribuée (consommable par webservices). Du coup, pas question de faire du traitement dans le front (controlleurs/vues).

Le modèle est très très simple, très peu de traitements métier. Mais par contre, les objets sont très riches en données et il existe beaucoup de relations entre eux. J'ai mis en place des services (via le pattern Service Layer) qui doivent assurer la validation et le filtrages des données, le contrôle des ACLs, etc etc.
Au départ je ne voulais pas, mais pour limiter le nombre de requêtes, pour envoyer des objets les plus riches possible en un seul échange, j'ai du mettre en place un pattern supplémentaire, le Data Transfer Object, accompagné du pattern Assembler.

En gros, mon front ne manipule que des DTOs, pas les objets métiers, mes services attendent des DTOs, transforment ces objets via des assembleurs en objets métiers, effectuent les traitements métiers et renvoient des DTOs. Mais tout dépend de ta couche métier, parfois les objets Doctrine peuvent suffir et un toArray() fera l'affaire et pas besoin de DTOs. Mes vues utilisent les DTOs qui possèdent exactement les données dont j'ai besoin (autre avantage ils sont totalement détachés de la persistance). Les avantages sont de pouvoir modéliser les DTOs comme on veut, en fonction des besoins, d'échanger un max d'info en un seul échange, de ne pas être influencé par un changement dans la persistance et/ou dans le modèle métier (il faudra juste adapter les assembleurs). Le gros gros inconvénient est le nombre d'objets supplémentaires que ça représente et la quantité de code qu'il faut pousser en plus, et ça ça peut vraiment refroidir.

Je ne sais pas comment faire pour rester simple, tout dépend vraiment de ce que tu veux faire
Parce que certains vont se dire : "houla, des DTOs et puis quoi encore, il part vraiment dans un délire celui là !".

Pour répondre plus directement à ta question. Pour moi, pour une appli. importante, voilà comment j'ai obtenu de la souplesse dans mon architecture :

métier :
    - entités
    - interfaces de repository pour les objets métiers

api :
    - interfaces des services
    - implémentations des services
    - validateurs (des Zend_Form améliorés qui servent de validateurs)
    - assembleurs Objets Métiers / DTOs
    - acls

data
    - implémentations des repository (persistance, DAO)
    - DTOs

front
    - controlleurs
    - vues

Et biensûr de l'injection de dépendance (IOC) obligatoire (et c'est un gros manque de zend actuellement) pour les tests unitaires et la maintenance de l'appli.

Le plus complexe a été d'apporter la validation dans les services tout en étant capable de retourner les erreurs de validation (plutôt qu'une pauvre Exception). Zend ne permet pas ça, car les formulaires sont prévus pour être dans le front.

Pour ça j'ai implémenté le pattern Notification proposé par Martin Fowler sur mes DTOs.

Tous ces choix pour une application. Pour une autre ça pourrait être bien différent !

Tout ça est très passionnant quand tu t'y intéresses, et quand j'en suis à faire du front et me rendre compte que tout roule, c'est le pied

Sur ce, j'espère ne pas être parti trop dans le détail.


A+ benjamin.

Et côté performance ça donne quoi toutes ces couches?