Zend FR

Mr.MoOx a écrit:

Moi je trouve ça intéressant.
Mais je comprends pas pourquoi ça ne serait plus aux controllers de filtrer et valider (= contrôler ?) tout ça ?
Ils serviraient à quoi alors les controllers?

Yeaah j'ai aggro quelqu'un !!

Salut

En fait, si nous imaginons une API qui pourra être utilisée par des tiers, c'est une perte de temps de développer notre propre front avec notre propre logique et ensuite de développer une API spécifique pour les tiers.

L'intérêt des services est que nous utilisons nous-même la même API que nous ouvrons à l'extérieur grâce aux webservices.

Imaginons un cas simple de CRUD, notre API (nos services) permet donc de manipuler les ressources. Nous ouvrons cette API vers le monde extérieur grâce aux webservices (presque rien à faire du coup), mais pour assurer une bonne robustesse nous devons s'assurer nous-même que les données qui nous serons envoyées soient filtrées et validées et non faire confiance aux consommateurs des services. Cette tâche doit donc être assurée par les services.

Quand nous allons construire notre propre "front" (nos vues et contrôleurs) par dessus notre modèle, inutile de répéter ces opérations, nous utiliserons directement notre API, celle là même qui est utilisée par les tiers. Les contrôleurs n'ont donc plus à s'inquiéter de la validation des données, ils ne font que consommer des méthodes de services. Dans mon schéma ils passent par les façades pour ne pas multiplier les services dont ils dépendent et n'avoir qu'un seul point d'entrée dans l'API. Notre front controlleur est donc un "aiguillage" et nos contrôleurs ne sont plus que de simples rails

Je dis plein de fois la même chose, mais c'est vrai que quand ça nous semble évident ce n'est pas forcément le cas pour les autres. Ces concepts existent depuis déjà un bout de temps, mais le monde objet de PHP est finalement tout neuf et il est temps d'aborder ces design qui font la robustesse d'autres langages :p
Les grands pontes de PHP et Zend se penchent certainement depuis déjà un moment sur la question, mais c'est bien d'en parler entre nous aussi et d'essayer de changer le monde


A+ benjamin.

Je découvre par ton texte, que les 'gens' autour de moi ne le font pas ??!

Tout le monde ne connais pas les bonnes pratiques de conception d'une appli, et même bcp qui les connaissent ne les mètent pas en application. Dès fois ça donne des controlleurs sans classe métier qui font plus de 1500 lignes. C'est moche mais c'est la triste réalité parfois.

Ce n'est pas si évident que ça. Comprendre une archi ou des concepts est une chose, les appliquer en est une autre. Sur le papier tout parait toujours merveilleux, mais une fois qu'on code on se heurte à plein de questions bloquantes et on devient parano de ne pas respecter comme on dit "les bonnes pratiques".

Il ne s'agit pas de "bonnes pratiques" ou de "tendances" ou quoi que ce soit. Lorsqu'on design des appli. complexes, l'orienté objet devient très complexe et très subtil.

Dans l'univers de PHP, c'est seulement depuis PHP5 que nous touchons à de la POO avancée, c'est donc très récent. Beaucoup de dév. PHP ignorent les concepts (design pattern) qu'ils ont à disposition pour designer une application complexe.

Aujourd'hui si je parle des services c'est parce qu'ils sont utilisés à toutes les sauces et la plupart du temps l'objectif est surtout de produire au mépris des notions de base de la POO.
Et ce sujet, et la façon dont les services sont utilisés dans la plupart des cas apportent beaucoup de questions de bon sens. Parce que les services c'est bien, mais finalement on fourre tout dedans.
Par ex. beaucoup d'entreprises qui utilisent JAVA adoptent une couche de services (façades de services) et fourrent non seulement la logique de leur application, mais aussi la logique métier dedans. Le résultat est, comme le dit Fowler, qu'on se retrouve avec des objets métiers qui n'en sont plus et ne sont plus que des gros sacs à setters et getters (Anemic Domain Model). Ca va à l'encontre du concept Objet, mais par contre c'est très facile à maintenir.

Et c'est là que c'est très subtil, comment distinguer ce qui est du ressort des contrôleurs ? du service ? de l'objet métier ? de la façade ? du DAO ? (etc.)

C'est ce genre de questions qui revient le plus souvent. Combien de sujets sur les fofos pour demander où placer une requête ? ou invoquer le modèle ? ou créer les formulaires ?

Mon rêve, c'est d'avoir un fil qui permet petit à petit de remettre tout ça dans l'ordre et évidemment de rester simples pour s'adapter à notre pauvre environnement script

Aujourd'hui (et depuis un moment) on nous sert du service, de la façade, du dao, du repository, de l'ORM, récemment "le DDD c'est le top". Essayons de replacer les choses dans leurs contextes.

Le Service pour moi, permet tout simplement de structurer une API par dessus le modèle et ainsi d'apporter de la souplesse dans le développement mais aussi des possibilités d'ouverture (webservices).
Mais ce n'est pas pour autant que le service doit tout porter.


Essayons de formuler un cas réel d'utilisation.

Nous voulons permettre à un utilisateur de créer des articles sur notre site.
L'utilisateur rempli donc un formulaire. Les données saisies sont ensuite validées par le serveur (et pas seulement par javascript !).
Si elles sont invalides, le formulaire déjà peuplé est ré-affiché avec des messages d'erreur.
Si elles sont valides, l'article est enregistré en base de données et l'utilisateur est redirigé sur une nouvelle page, par ex. l'article qu'il vient de saisir.

Quel est l'intérêt du service ici ?

A première vue, aucun. Le service n'est pas du tout obligatoire pour designer correctement cette application grâce à la POO (cf. Ruby par ex.).

Nous pourrions tout simplement créer nos objets métiers depuis les contrôleurs à partir du formulaire et demander directement à la couche d'accès aux données de faire persister cet objet.

Maintenant, notre site a énormément de succès, beaucoup de demandes nous parviennent pour pouvoir accéder aux articles et les manipuler directement sans passer forcément par notre site à nous.

C'est là que le service prend tout son sens. Je peux grâce aux services construire une API simple permettant de manipuler mon modèle (mes articles). De mon côtés mes contrôleurs n'ont qu'à communiquer avec cette API directement et je peux donner accès à l'API à des tiers via des webservices, facile.

Sur le papier c'est simple, mais de là découlent beaucoup de questions :

Qui construit l'objet métier ?

Ça pourrait être fait par toutes les couches, le contrôleur, l'objet lui même ou le service. Il n'y a pas LA bonne pratique.

Le contrôleur pourrait très bien créer l'objet et utiliser les setters pour le construire. Mais ça voudrait dire que le contrôleur est au courant du métier et sait donc quelles sont les propriétés à attribuer à l'objet. Pour moi c'est pas une bonne approche. Le contrôleur n'est pas au courant du métier, il sait juste comment utiliser des outils pour manipuler le modèle.

Au mieux, le contrôleur pourrait créer l'objet en lui envoyant toutes les données qu'il a, laissant l'objet se construire lui même avec ces données (new Article($form)), et ensuite appeler une méthode save() du service ArticleService.

En considérant que nous avons une API permettant de manipuler le modèle, il me parait plus logique de confier cette tâche à l'API. Le contrôleur qui consomme les méthodes du service reçoit les données du formulaire et demande simplement au service d'enregistrer un objet Article avec ces données.

Tout ceci est efficace à condition évidemment de structurer correctement les données qui sont attendues par le service.

Dans ce cas, qui valide les données ?

Un objet validateur spécifique, invoqué par le service ?

Les données sont validées directement dans le service ?

Tout dépend de comment on définit la "validation". Je reprend un exemple que j'ai vu sur le net et plutôt bien choisi.
Imaginons un paiement en ligne. L'utilisateur saisit un numéro de carte de crédit mais le nombre de chiffres ou le numéro ne correspond pas à un numéro de carte bancaire, c'est une erreur de validation. Maintenant le numéro de carte est syntaxiquement valide, mais la transaction est refusée par sa banque, est-ce une erreur de validation ?

L'utilisateur saisit "cent" au lieu de "100" dans le champ "montant", c'est une erreur de validation. Maintenant il saisit "100" mais il n'a pas les provisions suffisantes sur son compte bancaire, c'est une erreur de validation ?

L'utilisateur saisit correctement tous les champs, mais la transaction est refusée parce que sa carte est expirée. C'est une erreur de validation ?

Enfin je pense que vous avez compris

On distingue donc plusieurs types de validation.
Les validations des cohérences en terme de métier ne devraient-elles pas êtres assurées par les objets métiers directement et non pas par les services ? Alors que les erreurs de "transactions" devraient, elles, être gérées par les services.

Les objets devrait être "validable" et donc implémenter par exemple une interface "validatable" contenant une méthode "isValid()". Obligatoire parce que valider les données par les setters n'est pas suffisant. Par ex. l'utilisateur saisit "75001" comme code postal, ce code est valide. Mais il saisit "United States" comme pays, le code postal n'est donc plus valide. Il faut non seulement valider unitairement les données, mais aussi globalement d'un point de vue métier.

Mais si c'est l'objet qui assure cette fonction, comment construire des objets totalement indépendants du framework utilisé ? dois-je me passer des super validateurs et filtres de Zend ? :p

Je peux très bien décider de valider ses données à l'aide du service et d'une classe de validation indépendante. Mais dans ce cas, nos objets métier ne portent plus aucune règle "métier", il y a un truc qui cloche

Enfin, comment gérer efficacement les erreurs de "transactions" au sein des services ?

C'est à ce type de questions que j'aimerais qu'on essaie de répondre ensemble. Le sujet est très largement abordé sur le net. Mais ce qui serait bien c'est de réfléchir à une idée de l'implémenter avec PHP et notre beau framework Zend. Sans rentrer forcément dans le détails d'un point de vue code


A+ benjamin.

Intéréssant tout ça.
Je viens de tombé la dessus http://dev.juokaz.com/programming/servi … plications

Je ne pense pas que l'objet métier a un quelconque rôle de validation. Pour moi il ne devrait que retourner des valeurs filtrer ou pas et modifier ces données en retournant une Exception si incorrecte.

Le contrôle des données pour savoir si la propriété prix est bien un décimal devrait, selon moi, se faire dans le Service. Imaginons qu'on a un autre Service qui fait des validations différentes sur le même modèle en rajoutant le critère "prix > 2". Le fait que ça soit dans l'objet métier n'irait pas, à moins peut être d'étendre l'objet en utilisant le pattern Proxy. Au pire, je verrai l'objet métier retourner une exception si un Service à mal fait son travail.

Et les validations de transaction sont dans le même bateau que les validations de données à l'exceptions qu'elles peuvent interroger une base de données, mais je les vois également dans le Service avant d'appeler une méthode isValid.

Je me demande comment on pourrait associer l'objet Zend_Form dans notre Service ou alors utiliser comme dit @nicol@s une l'interface de validation.