Couche service, gestion des erreurs

[dorian53]

Bonjour,

Un exemple tout simple vaut mieux qu'une question compliquée.

Dans une couche service, une méthode addUser(oUser) permet d'ajouter un utilisateur en base de données.
Elle prend un objet utilisateur en paramètre.

La méthode addUser(oUser) valide l'entité avant ajout en base de données.
Imaginons les attributs login, mot de passe, email...

En cas d'erreur sur un ou plusieurs attributs, comment retournez-vous toutes les erreurs à la fois ?
Un tableau d'erreurs, un objet/collection d'erreurs, l'objet en entrée modifié, exceptions ?
Avez-vous une règle, une convention, etc... ?

Merci,
Dorian

 

[jv2759]

Tout dépend de ce qui existe déjà concernant la communication entre les différente couche.

il faut prendre également en compte les client potentiel (logiciel).

exceptions : cela peux être une idée, mais il faut être sur de qui vas l'utiliser et de l'effet rechercher.

Pour les autres solution, il faut rester logique avec ce que l'on à fait et coller avec sa philosophie.

Dans mon cas par exemple, qui ne s'applique que dans mon cas pour de la prog php, je fonctionne avec un objet de donnée et communication. A chaque fois je passe cette objet en entrer, et la fonction écris dans cette objet. Et je peux y écrire tout ce que je veux, donnée pour faire la réponse, message, erreur, même des message de debug. De plus j'ai prévus pour que cette objet puisse facilement être transmis d'un script php à l'autre, et même d'un scripte php à du javascript.

Il ne me reste plus qu'à lire cette objet pour savoir ce qui ne vas pas. De plus pour facilité le fonctionnement, j'ai doubler avec un retour à false des fonctions en cas d'erreur.

 

[spout]

Et ce sera pr nous laisser un vent comme pour l'autre topic ?
https://www.webrankinfo.com/forum/t/autocompletion-avec-optionbox-combobox.162236/ :lol:

 

[dorian53]

OK merci, intéressant jv2759 j'ai conçu le même système d'objet de réponse.
Il contient une méthode isValid(), les erreurs, la donnée retournée, etc... C'est très pratique en effet et j'étais plutôt satisfait pour les retours complexes et puis pour des méthodes plus simples telles que find(), count(), ou tout autre retour booléen, je me suis dit que cette objet réponse n'était pas forcément utile.
D'où plusieurs questions : dois-je continuer sur ce principe, à chaque méthode, pour certaines/lesquelles, etc. ?

spout, merci pour tes liens je voulais faire un retour après tests mais je n'ai pas eu le temps.

 

[jv2759]

C'est vrais que parfois cela peux paraitre lourd, mais cela à l'avantage d'uniformiser tout les échanges. Car par expérience le pire c'est à chaque fois de ce poser la question, c'est quoi le mieux ici. Car au final on ce trouve avec 500 méthode différente et quand on reviens on fini bien souvent par ce demander pourquoi on l'avait fait ainsi.

Pour des fonction plus simple du genre count, en effet ce n'est pas forcement l'idéale. Donc c'est vrais que je sépare, tout ce qui est donnée importante qui son potentiellement utile pour produire un résultat (je suis dans un contexte web), j'utilise mon objet. Mais pour les petit fonction plus simple donnant une info intermédiaire, alors je le fait directement, avec juste un renvois de false en cas de problème (ce qui est rarement limitant car la fonction fait alors qu'une seul chose, donc un seul type d'erreur possible).